Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c4a994aeec
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
.github/workflows/skills-release.yml
Outdated
| python - << 'PY' | ||
| from pathlib import Path | ||
| txt = Path('.release-policy.yml').read_text(encoding='utf-8') | ||
| auto = 'auto_release: true' in txt |
There was a problem hiding this comment.
In .github/workflows/skills-release.yml, the policy gate uses auto = 'auto_release: true' in txt, which treats comments or unrelated text as authoritative config; for example, a file containing auto_release: false plus a comment like # set auto_release: true later will still enable push-triggered releases. That can unintentionally create tags/releases on main even though the policy value is false, so this should read the actual YAML key/value (or at minimum ignore comments) before setting auto_release.
Useful? React with 👍 / 👎.
scripts/compute_next_version.py
Outdated
| m = TAG_RE.match(first) | ||
| if not m: | ||
| return (0, 0, 0) |
There was a problem hiding this comment.
latest_tag() reads git tag --list 'v*' --sort=-v:refname and only validates the first entry; if the top v* tag is non-semver (for example vnext), it returns (0, 0, 0) instead of using the next valid vX.Y.Z tag. In that scenario the workflow computes versions from v0.0.1 and can attempt duplicate or regressive tags despite existing releases.
Useful? React with 👍 / 👎.
.github/workflows/skills-release.yml
Outdated
| if [ -n "$PREV" ]; then | ||
| FROM="$PREV" | ||
| else | ||
| FROM=$(git rev-list --max-parents=0 HEAD) |
There was a problem hiding this comment.
When no prior release tag exists, the workflow sets FROM to the repository root commit, and the notes script diffs ${FROM}..${GITHUB_SHA}; for a first release run on the initial commit, FROM and TO are identical, so release notes incorrectly report no changed skills even though that release introduces them. This makes first-release notes misleading and should use a baseline that includes root-commit additions.
Useful? React with 👍 / 👎.
1 participant
Summary
skills/gecode-*skills from MPG into the new canonicalGecode/gecode-skillsrepoREADME.md), license (MIT), and release policy file (.release-policy.yml)Included
SKILL.mdandagents/openai.yaml.scripts/validate_skills.py:SKILL.mdfrontmatter fields (name,description)name == directoryscripts/compute_next_version.py:release:major,release:minor, default patch)scripts/build_release_notes.py:.github/workflows/skills-ci.yml:npx --yes skills add . --listsmoke discovery.github/workflows/skills-release.yml:workflow_dispatchmanual releasepush-to-mainauto path gated by.release-policy.ymlFirst Release Policy
.release-policy.ymlis set toauto_release: false.Local Validation
python3 scripts/validate_skills.pynpx --yes skills add . --listFollow-up
auto_release: true) to enable auto publish on merge tomain.