Repository navigation
Comparing changes
Open a pull request
base repository: cdalar/onctl
base: v0.1.29
head repository: cdalar/onctl
compare: v0.1.31
- 8 commits
- 9 files changed
- 3 contributors
Commits on Jul 7, 2026
-
build(deps): bump github.com/aws/aws-sdk-go-v2/config (#952)
Bumps [github.com/aws/aws-sdk-go-v2/config](https://github.com/aws/aws-sdk-go-v2) from 1.32.27 to 1.32.28. - [Release notes](https://github.com/aws/aws-sdk-go-v2/releases) - [Commits](aws/aws-sdk-go-v2@config/v1.32.27...config/v1.32.28) --- updated-dependencies: - dependency-name: github.com/aws/aws-sdk-go-v2/config dependency-version: 1.32.28 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Configuration menu - View commit details
-
Copy full SHA for b51a13c - Browse repository at this point
Copy the full SHA b51a13cView commit details
Commits on Jul 8, 2026
-
fix(fc): reconcile stale running/paused status against actual process…
… liveness onctl -p fc ls kept reporting microVMs as "running" indefinitely after their firecracker process died out-of-band — most notably a host reboot, which every firecracker VMM dies to but leaves metadata.json's last-written status untouched. Deploy() had the same blind spot: it treated a stale "running" record as proof the microVM was already up and silently no-op'd instead of recreating it. List/Deploy/GetByName now reconcile the persisted status against Process.IsRunning + Process.Owns (the same liveness check Destroy already used to guard against PID reuse), self-healing a stale record to a new "stopped" status on disk. Deploy() redeploys over a stopped record instead of returning it unchanged, and SSHInto now fails fast with a clear message instead of hanging against a dead socket.
Configuration menu - View commit details
-
Copy full SHA for 527d04a - Browse repository at this point
Copy the full SHA 527d04aView commit details -
fix(fc): let create's duplicate-name check skip stale stopped records
onctl create checks provider.List() for a same-named VM before calling Deploy, but List() includes fc records reconciled to "stopped" (dead process, e.g. after a host reboot). That made the check abort with "VM exists" instead of ever reaching Deploy's stale-record recreate path, defeating the reconciliation added in the previous commit. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RuNxaYWJi7HTNLUAZjPC1y
Configuration menu - View commit details
-
Copy full SHA for 2bf29e1 - Browse repository at this point
Copy the full SHA 2bf29e1View commit details -
Merge pull request #954 from cdalar/fix/fc-reconcile-stale-status
fix(fc): reconcile stale running/paused status against actual process liveness
Configuration menu - View commit details
-
Copy full SHA for 9ba7d86 - Browse repository at this point
Copy the full SHA 9ba7d86View commit details -
fix(fc): use "dead" status, not "stopped", for a reboot-killed microVM (
#955) PR #954's reconciliation persisted a dead fc microVM's status as "stopped" — but cmd/list.go's isPausedStatus() already treats the literal string "stopped" as the cross-provider paused/resumable convention (AWS "stopped", GCP "TERMINATED", Azure "deallocated") and folds it into onctl ls's PAUSED section. That collision made a reboot-killed microVM (no restart-from-disk, must be destroyed and recreated) render as merely "paused" (implying it can be resumed), which is exactly what this fix was supposed to stop lying about. Renames fcStatusStopped to fcStatusDead ("dead") throughout pkg/cloud and the cmd/create.go duplicate-name check, and adds TestIsPausedStatus in cmd/list_test.go to lock in the distinction.
Configuration menu - View commit details
-
Copy full SHA for 5dbb06e - Browse repository at this point
Copy the full SHA 5dbb06eView commit details -
build(deps): bump google.golang.org/api from 0.287.0 to 0.287.1 (#956)
Bumps [google.golang.org/api](https://github.com/googleapis/google-api-go-client) from 0.287.0 to 0.287.1. - [Release notes](https://github.com/googleapis/google-api-go-client/releases) - [Changelog](https://github.com/googleapis/google-api-go-client/blob/main/CHANGES.md) - [Commits](googleapis/google-api-go-client@v0.287.0...v0.287.1) --- updated-dependencies: - dependency-name: google.golang.org/api dependency-version: 0.287.1 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Configuration menu - View commit details
-
Copy full SHA for 22628d8 - Browse repository at this point
Copy the full SHA 22628d8View commit details -
build(deps): bump github.com/aws/aws-sdk-go-v2/service/ec2 (#957)
Bumps [github.com/aws/aws-sdk-go-v2/service/ec2](https://github.com/aws/aws-sdk-go-v2) from 1.311.0 to 1.313.0. - [Release notes](https://github.com/aws/aws-sdk-go-v2/releases) - [Commits](aws/aws-sdk-go-v2@service/ec2/v1.311.0...service/ec2/v1.313.0) --- updated-dependencies: - dependency-name: github.com/aws/aws-sdk-go-v2/service/ec2 dependency-version: 1.313.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Configuration menu - View commit details
-
Copy full SHA for 29fcb60 - Browse repository at this point
Copy the full SHA 29fcb60View commit details -
fix(release): sign checksums with explicit GPG key in isolated keyring (
#958) * fix(release): sign checksums with explicit GPG key in isolated keyring The self-hosted release runner is persistent (not ephemeral), so the shared ~/.gnupg default keyring can end up in a state where gpg can't resolve an unambiguous default signing key, failing with "no default secret key: No public key". Import the key into a job-scoped GNUPGHOME and have goreleaser sign with the imported key's fingerprint explicitly instead of relying on gpg's default-key guess. * fix(ci): write proper KEY=VALUE to GITHUB_ENV for GNUPGHOME echo "$GNUPGHOME" >> "$GITHUB_ENV" wrote just the value with no key, which GitHub's env-file parser rejects ("Invalid format"). Test run against v0.1.30 caught this before it could hit a real release. * ci(release): disable actions/setup-go cache on the self-hosted runner GOCACHE/GOMODCACHE already persist on this runner's disk between runs since it's a long-lived machine, not ephemeral. Uploading/ downloading GitHub's remote Actions cache on top of that just adds several minutes of upload time for a multi-GB cache with no benefit.
Configuration menu - View commit details
-
Copy full SHA for 79f3031 - Browse repository at this point
Copy the full SHA 79f3031View commit details
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff v0.1.29...v0.1.31