[compot-dev]

Closes #66.

• .github/workflows/version.yml (new): runs .github/check-version.sh HEAD^1 on pull requests with NO_RELEASE from the no-release label. It is the only workflow that listens to labeled/unlabeled, so a label change re-runs this check, not every build. Same layout as OpenIPC/camex.
• build.yml: the version job and the label event types are gone; the release job (head-only publish) is unchanged.
• check-version.sh: comment only (where CI runs it; version.yml is CI, not build).
• README (three languages): the build workflow counts as build; the no-release label covers a change that leaves the release files as they are.

Checked locally: shellcheck v0.10.0 clean; both workflows parse as YAML; check-version.sh against master on this branch: fails without NO_RELEASE (build.yml changed, version still 1.9.0), passes with it.

CI only: no version bump, hence the no-release label.

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

PR Summary by Qodo

Run pull-request version checks in a separate workflow

⚙️ Configuration changes 📝 Documentation 🕐 10-20 Minutes

AI Description

• Move version checks into a pull-request workflow so label changes no longer rerun builds.
• Preserve version and changelog enforcement, including the no-release label exception.
• Clarify release-version rules in all three READMEs.

Diagram

graph TD
  PR["PR updates"] --> Build["Build workflow"] --> Artifacts["Build artifacts"]
  PR --> Version["Version workflow"] --> Checker["Version checker"] --> Policy["Version policy"]
  Labels["Label changes"] --> Version

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Keep one workflow and gate build jobs by event type

• ➕ Retains a single workflow file.
• ➖ Adds event conditions to build jobs and still starts the build workflow on label changes.

Recommendation: Keep the separate workflow. It isolates label-triggered checks without adding conditional logic across the build jobs.

Files changed (6) +65 / -32

Documentation (4) +19 / -12

check-version.shIdentify the version workflow as the CI caller +3/-2

Identify the version workflow as the CI caller

• Clarifies in a comment that version.yml passes the pull-request merge commit's first parent as the comparison base. Validation behavior is unchanged.

.github/check-version.sh

README.mdClarify English release-version rules +6/-4

Clarify English release-version rules

• Identifies the build workflow as a version-relevant change and explains when the no-release label replaces a version bump. Names the new workflow that runs the check.

README.md

README.ru.mdClarify Russian release-version rules +5/-3

Clarify Russian release-version rules

• Documents the build-workflow exception, the no-release label, and the dedicated version-check workflow in Russian.

README.ru.md

README.zh-CN.mdClarify Chinese release-version rules +5/-3

Clarify Chinese release-version rules

• Documents the build-workflow exception, the no-release label, and the dedicated version-check workflow in Chinese.

README.zh-CN.md

Other (2) +46 / -20

build.ymlRemove version checks and label triggers from builds +4/-20

Remove version checks and label triggers from builds

• Removes the version job and explicit label events from the build workflow. Build and release jobs remain in place.

.github/workflows/build.yml

version.ymlRun version checks on pull-request and label events +42/-0

Run version checks on pull-request and label events

• Adds a dedicated workflow that checks out full history and runs check-version.sh against HEAD^1. It passes the current no-release label state and cancels superseded checks for the same pull request.

.github/workflows/version.yml

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

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

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 ↗