Repository navigation
release: one release "latest" titled "Cerberus <version>", published on a version bump; cerberus 0.3.1 (#32) - #37
Merged
Conversation
…on a version bump; cerberus 0.3.1 (#32) - ci.yml: the release job runs on master (pushes and manual runs) after lint, test and build; it reads CERBERUS_VERSION and publishes only when it differs from the version in the title of the current "latest": the binaries just built and tested, the installers, the license and SHA256SUMS (ci/assemble.sh), "latest" deleted with its tag and created again on the built commit, titled "Cerberus <ver>". A failed lookup of "latest" (other than not found) stops the job. The v* tag trigger is gone; on master a newer push waits instead of cancelling. - ci/build.sh: the compiled version is CERBERUS_VERSION in src/cerberus.c (VERSION overrides it for a test build only); no git describe, so the build no longer needs the tags or a full clone. - CERBERUS_VERSION 0.3.1: the first release under this scheme. - READMEs: "Releases" and "CI and releases" describe the one release and how to publish (bump the version with its CHANGELOG.md section). - CHANGELOG.md: 0.3.1. The v0.1.0...v0.3.0 releases and tags are removed after the first latest is checked (their notes are in CHANGELOG.md, #35). Tested: ci/build.sh (all four arches, compot cache): no warnings, ELF and TLS checks under QEMU pass, sizes as in 0.3.0, cerberus --help says 0.3.1; tests/run.sh 172 passed, 8 failed — the WireGuard data-plane checks that cannot run in this sandbox (no NET_ADMIN), as on master; shellcheck v0.10.0 -S warning clean. Closes #32
PR Summary by QodoPublish a single latest release when the Cerberus version changes
AI Description
Diagram
High-Level Assessment
Files changed (7)
|
Code Review by Qodo
1. The old latest release record remains
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
…place Qodo on #37: - a rerun of an older master workflow could replace a newer latest and roll the cameras back: the job publishes only when the built commit is the head of master (git ls-remote), otherwise it says so and stops. - deleting latest before creating it again left the installer's releases/latest/download links without files if the create failed: an existing latest is now updated in place — the files replaced (--clobber), the tag moved to the built commit, then the title and notes. Only the very first publication creates it (moving a left-over latest tag first). Refs #32
Collaborator
Author
|
Qodo findings, both fixed in f596de5:
|
Collaborator
Author
|
/review |
Thanks for the update. Based on
I can’t mark findings implemented from this chat, but the cited changes appear to address both reported failure modes. |
Comment on lines
+179
to
+183
| if [ "$EXISTS" = 1 ]; then | ||
| # in place: files first, then the tag, then the title and notes | ||
| gh release upload latest dist/* --repo "$GITHUB_REPOSITORY" --clobber | ||
| gh api -X PATCH "repos/${GITHUB_REPOSITORY}/git/refs/tags/latest" -f sha="$GITHUB_SHA" -F force=true >/dev/null | ||
| gh release edit latest --repo "$GITHUB_REPOSITORY" --latest --title "Cerberus ${VER}" --notes-file notes.md |
There was a problem hiding this comment.
1. The old latest release record remains 📎 Requirement gap ≡ Correctness
The Publish branch for an existing release uploads over latest and edits it instead of deleting it with --cleanup-tag. Whenever latest already exists, its release record is retained and only its assets, tag target, title, and notes are mutated, so the required delete-and-recreate publication is not performed.
Agent Prompt
## Issue description
The existing `latest` release is edited in place rather than deleted with its tag and recreated on the built commit, which does not satisfy the required release replacement flow.
## Fix Focus Areas
- .github/workflows/ci.yml[179-183]
## Recommended Fix
Replace the existing-release upload and edit branch with a `gh release delete latest --cleanup-tag` operation followed by `gh release create latest` using the assembled assets, `--latest`, the built commit, the `Cerberus <version>` title, and the generated notes.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| NOTES | ||
| if [ "$EXISTS" = 1 ]; then | ||
| # in place: files first, then the tag, then the title and notes | ||
| gh release upload latest dist/* --repo "$GITHUB_REPOSITORY" --clobber |
There was a problem hiding this comment.
2. Camera installs can fail during an update 🐞 Bug ☼ Reliability
gh release upload latest dist/* --clobber replaces release assets separately, exposing binaries and SHA256SUMS from different builds while publication is in progress. An installer that fetches those files on opposite sides of a replacement fails checksum verification; an upload failure can leave that mismatch in place until publication is retried.
Agent Prompt
## Issue description
Updating the live release replaces assets separately, so installers can fetch a binary and checksum from different builds. A failed upload can leave that state in place.
## Fix Focus Areas
- .github/workflows/ci.yml[179-183]
- install.sh[95-105]
## Recommended Fix
Make publication recover from a partially replaced asset set, and have the installer retry fetching both the binary and checksum when they disagree during a release update. Ensure a failed upload cannot leave the live release permanently inconsistent.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
|
Code review by qodo was updated up to the latest commit f596de5 |
Qodo on #37: if a publication was cut off after the title was set, later runs at the same version skipped it and left files missing for the installer. With the same version in the title the job now checks the release's files (the four binaries, the installers, LICENSE.md, SHA256SUMS) and publishes again when one is missing. Refs #32
Collaborator
Author
|
Qodo findings on f596de5:
|
Collaborator
Author
|
/review |
Understood. Your rationale addresses the three current findings:
The findings remain open in Qodo’s review until explicitly dismissed; no review or PR changes were performed. |
|
Code review by qodo was updated up to the latest commit 0bf8925 |
Collaborator
Author
|
Qodo finding 6 (camera releases can point to old commits): fixed in 661f338. On the first-publication path the job checks whether a |
Collaborator
Author
|
/review |
Collaborator
|
Looks good — in-place update, the head-of-master guard and the asset check cover what I raised on #32. Merging once the test jobs are green. |
Comment on lines
+126
to
+127
| head=$(git ls-remote origin refs/heads/master | cut -f 1) | ||
| if [ "$head" != "$GITHUB_SHA" ]; then |
There was a problem hiding this comment.
6. A newer push can leave older binaries live 🐞 Bug ≡ Correctness
A new version? checks the head of master only once, before downloading artifacts and publishing the release. If another commit with the same version lands after that check, the older run can publish its binaries, while the newer run sees a complete release with the expected title and skips publication.
Agent Prompt
## Issue description
A push can advance `master` after the release job's sole head check, allowing an older run to publish assets that a subsequent same-version run will not replace.
## Fix Focus Areas
- .github/workflows/ci.yml[125-129]
- .github/workflows/ci.yml[174-200]
## Recommended Fix
Check the remote head again immediately before mutating the release. If it has advanced, exit without publishing so the queued run can publish from the newer commit.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
|
Code review by qodo was updated up to the latest commit 661f338 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #32. cerberus 0.3.1.
What changes
ci.yml): runs onmaster(pushes and manual runs) afterlint,test,build. It readsCERBERUS_VERSIONand publishes only when it differs from the version in the title of the currentlatest(releases/latest/download/install.shis what new cameras install, so a release stays a deliberate version bump):SHA256SUMS(ci/assemble.sh);latestdeleted with its tag and created again on the built commit,--latest, titleCerberus <version>, short notes (install command, CHANGELOG, README);latest(anything but "not found") stops the job; a push without a new version publishes nothing.v*tag trigger is gone. Onmastera newer push waits instead of cancelling a running workflow (no release cut off between delete and create); a manual run shares the push group.ci/build.sh: the compiled version isCERBERUS_VERSIONfromsrc/cerberus.c(VERSIONoverrides it for a test build only);git describeis gone, so the build no longer needs tags orfetch-depth: 0.CERBERUS_VERSION0.3.1, the first release of the new scheme;CHANGELOG.md0.3.1.latest,Cerberus <version>) and "CI and releases" (how a release is published; thegit tagexample is gone).After the merge: check the first
latest(Cerberus 0.3.1, the same file names,SHA256SUMS), then remove thev0.1.0…v0.3.0releases and tags (their notes are inCHANGELOG.mdsince #35).Tests
ci/build.sh, all four arches--helpand the X25519/TLS checks under QEMU pass; sizes as in 0.3.0 (arm 308 396, mipsel 397 796, aarch64 337 432, x86_64 317 000);cerberus --help→cerberus 0.3.1tests/run.shNET_ADMIN, which this sandbox lacks; they fail the same way onmasterlocally and pass in CIshellcheckv0.10.0-S warningCHANGELOG.mdsection