Skip to content

ci: register the version on foundryvtt.com from the release job - #22

Merged
fcsouza merged 1 commit into
masterfrom
ci/foundry-release-api
Sep 14, 2026
Merged

fcsouza merged 1 commit into
masterfrom
ci/foundry-release-api

Conversation

@fcsouza

@fcsouza fcsouza commented Sep 14, 2026

Copy link
Copy Markdown
Owner

The site keeps its own list of versions, and here it is filled in through a form by hand. It sat four versions behind: 2.0.2, 2.0.3, 2.0.4 and 2.1.0 were released in this repository and never appeared there, so nobody could install them from the site or be offered the update. 3.0.0 I added by hand today; this makes the next one automatic.

How

The Package Release API takes the same fields over HTTP: id plus a release object with version, manifest, notes and compatibility.

Three decisions worth naming:

  • It runs last. The site fetches the manifest to validate the entry, and that file is a release asset. Before the GitHub release exists it is a 404.
  • The manifest URL names the tag, not latest. An entry describes one version, and a moving URL would make every old entry install the newest build.
  • Compatibility is read out of dist/module.json, the manifest that was just built, so the site and the package cannot drift apart.

The answer body is printed before the status code is judged: a refusal explains itself there, and a step that shows only the number hides why.

What you have to do once

gh secret set FOUNDRY_RELEASE_TOKEN --repo fcsouza/pdf-character-sheet

Paste the Package Release Token from the package edit page when it asks. Without the secret the step stops with a message saying exactly that, rather than failing somewhere obscure.

Checked

The same step is already on master in vttforge/settings-vault, where the payload was proven against the live API with "dry-run": true and came back status: success. Here the workflow parses and the step lands after Create GitHub Release.

It has not run against the API for this package yet. That happens on the next tag, and it fails loudly if anything is wrong.

The site keeps its own list of versions, filled in by hand through a form. It
sat four versions behind: 2.0.2, 2.0.3, 2.0.4 and 2.1.0 were released here and
never appeared there, so nobody could install them from the site or be offered
the update.

The Package Release API takes the same fields over HTTP. The step runs last,
because the site fetches the manifest to validate the entry and that file is a
release asset: before the release exists it is a 404.

The manifest URL names the tag rather than `latest`. An entry describes one
version, and a moving URL would make every old entry install the newest build.
Compatibility is read out of the manifest that was just built, so the site and
the package cannot drift apart.

Needs FOUNDRY_RELEASE_TOKEN in the repository secrets. Without it the step
stops and says where to get the token.
@fcsouza
fcsouza merged commit b74a141 into master Sep 14, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant