CI: add a v14 stable publish track, guard both against publishing the wrong version line#49
CI: add a v14 stable publish track, guard both against publishing the wrong version line#49gharezlak wants to merge 1 commit into
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".
| # new v13-latest). | ||
| jq --arg repo "$REPO" \ | ||
| '.manifest = "https://github.com/\($repo)/releases/download/v14-latest/module.json" | | ||
| .download = "https://github.com/\($repo)/releases/download/v14-latest/module.zip"' \ |
There was a problem hiding this comment.
When a later v14 build is published, every older versioned module.json that this workflow already submitted to Foundry via the ${{ env.RELEASE_NAME }} manifest URL will still have download pointing at the moving v14-latest asset. Foundry's package docs say each package-version manifest should download the zip for that specific release, and installs use the manifest's download URL, so users who need an older compatible v14 version can end up installing the newest v14 zip instead; keep manifest on v14-latest for update checks, but make download point at ${{ steps.get_version.outputs.TAG }}/module.zip.
Useful? React with 👍 / 👎.
| name: Release ${{ steps.get_version.outputs.VERSION }} (v14) | ||
| body_path: release_notes.md | ||
| draft: false | ||
| prerelease: false |
There was a problem hiding this comment.
When this first v14 stable release is created as a non-prerelease, GitHub's repo-wide /releases/latest URL can start serving the v14 assets, but the current checked-in module.json and already-published v13 release assets still point installed v13 users at /releases/latest. Those users will fetch the v14 manifest on update before the new v13-latest URL helps them, so please add a one-time v13 manifest/listing migration or block this publish path until existing v13 installs have been moved off the global latest URL.
Useful? React with 👍 / 👎.
| 1. Merge tested `staging` work into `release/v14` (create the branch from | ||
| `staging` if it doesn't exist yet) |
There was a problem hiding this comment.
Following this instruction to create release/v14 from staging will leave the newly added .github/workflows/auto-release-v14.yml behind on main. For push events, GitHub evaluates workflow files from the pushed ref, so the subsequent version bump on release/v14 will not run or publish unless this workflow file is also present on that branch; create the branch from a commit that includes the workflow or explicitly merge/cherry-pick it first.
Useful? React with 👍 / 👎.
| id: create_release | ||
| uses: softprops/action-gh-release@v1 | ||
| with: | ||
| tag_name: ${{ steps.get_version.outputs.TAG }} |
There was a problem hiding this comment.
In the release/v14 workflow, this action creates the version tag when v2.x does not already exist, but softprops/action-gh-release passes an unset target_commitish through to GitHub, whose create-release API defaults the tag to the repository's default branch. Because this job is building assets from release/v14, the v2.x GitHub tag/source archive will point at main's v13 commit; set target_commitish: ${{ github.sha }} or pre-create the tag so the published version tag matches the build.
Useful? React with 👍 / 👎.
2 participants
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