[compot-dev]

Closes #62. Closes #63. Closes #64.

• .github/check-version.sh follows OpenIPC/vtesse and OpenIPC/cerberus: one PROGRAM_VERSION definition (any other count fails), the format checked only when the version changes, Markdown files in the code paths ignored. CI calls it with HEAD^1, the base side of the pull request's merge commit, which is what CI tested (check-version.sh: compare with HEAD^1 and skip Markdown, as in vtesse #63).
• The build workflow counts as build: it builds the release files, so a change to it needs a new version. A change that leaves the release files as they are (a test or publication step, a build-script tidy-up) takes the no-release label and passes without one, as in ci: a no-release label lets a change that keeps the binaries skip the version; review follow-ups cerberus#39; the workflow now also runs on labeled/unlabeled (Version check: workflow build steps and a no-release label #64).
• The release job compares GITHUB_SHA with git ls-remote origin refs/heads/master and publishes only from the head of master; otherwise it leaves a notice and does nothing, so a re-run of an older run cannot roll latest back (Release: publish "latest" only from the head of master #62).

This pull request changes only CI and keeps the release files as they are: no-release, no version bump.

Checked locally (debian bookworm container): shellcheck v0.10.0 clean; the script against 12 synthetic cases — code change without a bump fails and passes with NO_RELEASE=true, a workflow-only change fails and passes with NO_RELEASE=true, docs, Markdown in ci/ and other .github/ files pass, bump with a CHANGELOG section passes, a missing section, a lower version, a leading zero and two definitions fail; on this branch against master it fails without the label and passes with it.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Check release versions against PR merges and publish only from master’s head

🐞 Bug fix ✨ Enhancement ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Validate versions against the tested PR merge base, counting build-workflow changes but excluding
 Markdown files.
• Allow unchanged release files through with a no-release label and rerun checks when labels
 change.
• Skip publication when the run’s commit is no longer the head of master.

Diagram

graph TD
  PR["PR merge"] --> Version{"Version gate"} -->|"Bump or no-release"| Pass["Pass check"]
  Version -->|"Otherwise"| Fail["Fail check"]
  Builds["Master builds"] --> Head{"Current head?"} -->|"Yes"| Publish["Publish latest"]
  Head -->|"No"| Skip["Skip publication"]

Loading

High-Level Assessment

The approach fits the existing workflow: use the merge commit’s first parent to check what CI tested, permit an explicit label for changes that do not affect release files, and guard publication after builds. Canceling older master runs instead was considered but would risk interrupting release replacement.

Files changed (2) +65 / -23

Bug fix (1) +42 / -18

check-version.shTighten version checks and recognize no-release changes +42/-18

Tighten version checks and recognize no-release changes

• Requires exactly one PROGRAM_VERSION definition, and checks version format when the version changes. Counts the build workflow among release-relevant paths, excludes Markdown files from those paths, and allows an unchanged version when NO_RELEASE=true.

.github/check-version.sh

Other (1) +23 / -5

build.ymlRecheck PR labels and prevent stale release publication +23/-5

Recheck PR labels and prevent stale release publication

• Reruns on PR label changes and passes the label state and merge commit’s first parent to the version check. Before publishing, compares the run SHA with the remote master head and skips publication when they differ.

.github/workflows/build.yml

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (1) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. A label can ship changed binaries 📎 Requirement gap ≡ Correctness

Description

The NO_RELEASE branch accepts any nonempty changed set without checking whether the resulting
release files differ from the base revision. When the label is present on a source or build change
that alters a binary, the script exits successfully and the workflow proceeds to build and publish
it without a version bump.

Code

.github/check-version.sh[R46-50]

+	if [ -n "$changed" ] && [ "${NO_RELEASE:-}" = true ]; then
+		echo "::notice::code or build changed, PROGRAM_VERSION stays $old: the no-release" \
+			"label says the release files do not change"
+		echo "$changed"
+		exit 0

Evidence

Compliance ID 2 requires a no-release label to pass only when binaries remain unchanged and
explicitly treats exempting binary-changing work as failure. The added branch checks only that
NO_RELEASE is true and that some tracked path changed; it performs no release-file or binary
comparison before exiting successfully.

Allow explicitly labeled binary-neutral changes without a version bump
.github/check-version.sh[46-50]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `NO_RELEASE` label unconditionally bypasses the version requirement for every changed code or build path, including changes that alter released binaries. The label must only bypass the check after the release outputs are proven unchanged.
## Fix Focus Areas
- .github/check-version.sh[46-50]
## Recommended Fix
Before accepting `NO_RELEASE=true`, compare the release files produced from the pull request with those from the base revision, or restrict the bypass to an explicit, reliably validated set of binary-neutral changes. Exit with an error when the label is present but release outputs differ, and retain the current success path only when the outputs are unchanged.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. A newer push can still publish old binaries 🐞 Bug ≡ Correctness

Description

The Branch head step checks master only once, before the separate Publish step reads and
replaces the release. If a newer push arrives after that check, the older run can delete latest,
publish its obsolete artifacts, and announce them while the newer run waits.

Code

.github/workflows/build.yml[R238-241]

+          head=$(git ls-remote origin refs/heads/master | cut -f 1)
+          if [ "$head" != "$GITHUB_SHA" ]; then
+            echo "::notice::master is at ${head:0:7} now, not ${GITHUB_SHA::7}: not published"
+            echo "skip=true" >> "$GITHUB_OUTPUT"

Evidence

Master runs are not canceled, and the publish gate uses only the earlier step's output. The publish
step subsequently deletes and recreates latest for its own SHA without rechecking master; its
output can also trigger Telegram.

.github/workflows/build.yml[36-40]
.github/workflows/build.yml[233-246]
.github/workflows/build.yml[272-283]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A new master commit can arrive after the branch-head check but before the older run replaces `latest`.
## Fix Focus Areas
- .github/workflows/build.yml[233-246]
- .github/workflows/build.yml[250-278]
## Recommended Fix
Revalidate the remote branch head immediately before changing `latest`, and design the publication guard so a branch update between validation and replacement cannot publish an obsolete commit.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Remote lookup failures silently skip releases ✓ Resolved

Description

The git ls-remote command is piped into cut without pipefail, so a failed lookup leaves head
empty without failing the step. When the remote cannot be queried, the comparison sets skip=true
and the release job succeeds without attempting publication.

Code

.github/workflows/build.yml[R238-241]

+          head=$(git ls-remote origin refs/heads/master | cut -f 1)
+          if [ "$head" != "$GITHUB_SHA" ]; then
+            echo "::notice::master is at ${head:0:7} now, not ${GITHUB_SHA::7}: not published"
+            echo "skip=true" >> "$GITHUB_OUTPUT"

Evidence

The pipeline assigns cut's successful status to the lookup, while an empty result differs from
GITHUB_SHA. The resulting skip output makes the only publication step conditional false.

.github/workflows/build.yml[235-246]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A failed remote branch lookup is treated as a successful decision not to publish.
## Fix Focus Areas
- .github/workflows/build.yml[235-242]
## Recommended Fix
Make the lookup failure propagate, such as by enabling `pipefail`, and reject an empty SHA before comparing it with `GITHUB_SHA`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can move or hide resolved findings to focus on what still needs action

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[compot-dev]

/review

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit 4f2c68a