CI: add a v14 stable publish track, guard both against publishing the wrong version line - #49
Merged
Conversation
Foundry's package page already supports one listing with multiple versions, each carrying its own compatibility range, so publishing v14 alongside v13 needs no registry restructuring — just a second publish path feeding the same module id. - New auto-release-v14.yml: mirrors auto-release.yml but triggers on push to release/v14, requires module.json version 2.x / compat 14.x, and publishes to the same FOUNDRY_ADMIN_MODULE_ID as a separate version entry. - Both stable workflows now refuse to run if module.json's version/ compatibility don't match their expected family (1.x/13.x for main, 2.x/14.x for release/v14). This directly targets the mechanism found in git history behind the original incident: auto-release.yml fires on any push to main that bumps module.json, and a v14-shaped commit once landed there under a v13 version string. - Fixed a related bug: module.json's own manifest/download URLs used GitHub's "releases/latest", which is repo-wide — with two stable tracks publishing non-prerelease releases to the same repo, whichever published most recently would silently take over the other track's "latest" URL. Each track now owns its own moving tag (v13-latest / v14-latest), mirroring how beta-release.yml already does this for beta-latest. - Updated .github/RELEASE_WORKFLOW.md for the new dual-track model. Not run/triggered as part of this change — no push to release/v14 or main has been made, so no live publish has occurred. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
![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: ad66abcb06
ℹ️ 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".
Owner
|
@greptile-apps please review this |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Reject prerelease/non-semver module.json versions before publishing. Let only the versioned v13 release claim GitHub's Latest pointer. Co-authored-by: Cursor <cursoragent@cursor.com>
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
2 participants
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.
Context
We want two live version lines on the same Foundry package listing: legacy v13 (`main`, 1.x) and v14 (2.x). Foundry's package page already supports one listing with multiple versions, each with its own compatibility range — confirmed by checking the actual live listing (foundryvtt.com/packages/archivist-sync), so this needs no registry restructuring, just a second stable-publish path feeding the same module id.
This also closes a real gap found while tracing the mechanics of the v14-breaks-v13 incident this project is recovering from: `v1.3.13` and `v2.0.0-beta.28` were tagged on the identical commit in this repo's history, and `auto-release.yml` fires a real Foundry publish on any push to `main` that bumps `module.json` — no check that the version being published is actually in the right family. That's precisely the shape of mistake that would let a v14-configured commit publish under a v13-looking tag (or vice versa).
What's here
auto-release-v14.yml: mirrorsauto-release.ymlbut triggers on push to a newrelease/v14branch (doesn't exist yet — this workflow is inert until it's created), publishes to the sameFOUNDRY_ADMIN_MODULE_IDas a separate version entry, requiresmodule.jsonversion2.x/compatibility.minimum14.x.auto-release.ymlnow refuses to run unless version is1.xandcompatibility.minimumis13.x; the new v14 workflow mirrors that for2.x/14.x. Either one fails loudly and exits before touching the release/publish steps if the version doesn't match its branch's expected family.module.jsonmanifest/downloadfields used to point at GitHub's built-inreleases/latest, which is repo-wide — once a second stable track also publishes non-prerelease releases to this repo, whichever published most recently would silently take over the other track's "latest" URL, pointing a v13 user's stored manifest at v14'smodule.jsonor vice versa. Each track now owns its own moving tag (`v13-latest` / `v14-latest`), mirroring how `beta-release.yml` already does this for `beta-latest`.What this does NOT do
Doesn't create `release/v14` or push anything that would actually fire a publish — that's a deliberate next step once #47/#48 are reviewed and merged, not part of this PR. Nothing here changes current
mainpublish behavior beyond the added guard (which only blocks a publish that was already wrong).🤖 Generated with Claude Code
Greptile Summary
This PR establishes a dual stable-publish track by adding
auto-release-v14.yml(triggering onrelease/v14) alongside the updatedauto-release.yml(onmain), both publishing to the same Foundry package listing under separate compatibility ranges. It also closes a real latent bug: both workflows now rewrite themodule.jsonmanifest to their own moving tag (v13-latest/v14-latest) instead of the repo-widereleases/latestURL, preventing one track's publish from silently hijacking the other track's update pointer.auto-release-v14.yml: mirrors the v13 workflow with correct concurrency serialization, pre-release version guard (rejects*-*strings),make_latest: falseon all releases to preserve the v13 Latest badge, and av14-latestmoving tag.auto-release.ymlupdates: adds a symmetric version-family guard (rejects non-1.xversions and non-13.xcompat), upgrades tosoftprops/action-gh-release@v2, introduces av13-latestmoving tag, and moves inline${{ }}expressions intoenv:blocks.RELEASE_WORKFLOW.mdis updated with a dual-track branch diagram, a one-time pre-v14 cutover checklist, and updatedmanifest/downloadURL examples.Confidence Score: 5/5
Safe to merge — the new workflow is inert until
release/v14is created, and the only behavioral change to the currently-activemainpath is the added version guard and thev13-latestmoving tag, both of which fail loudly rather than silently.The core risk this PR guards against (wrong-track publish) is addressed with explicit, noisy early exits. The new
auto-release-v14.ymlcannot fire until arelease/v14branch is pushed. The moving-tag pattern mirrors the already-provenbeta-latestapproach. The only findings are edge-case false-positive guards on bare-integer Foundry compat values, which produce loud CI failures rather than silent bad publishes.Files Needing Attention: No files require special attention — the two suggestions on the COMPAT_MIN glob are low-priority and both workflows are otherwise structurally sound.
Important Files Changed
make_latest: false, andv14-latestmoving tag; minor: COMPAT_MIN glob rejects valid bare-integer Foundry compat values.v13-latestmoving-tag logic, and concurrency group; upgraded action to@v2;make_latestset correctly on both releases; COMPAT_MIN glob has the same bare-integer edge case as the v14 workflow.v13-latest/v14-latestmoving-tag explanation, pre-v14 cutover checklist, and warnings aboutrelease/v14bootstrap ordering.Reviews (2): Last reviewed commit: "fix: harden stable release guards and La..." | Re-trigger Greptile