Skip to content

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

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

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

Conversation

@fcsouza

@fcsouza fcsouza commented Sep 14, 2026

Copy link
Copy Markdown
Contributor

Filling the version form on foundryvtt.com by hand was the last manual step left in a release. The site keeps its own list of versions, and a package with no entry there cannot be installed from the site and offers nobody an update.

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 vttforge/settings-vault

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 workflow parses, and the step lands after Create GitHub Release. The payload jq builds, against the real dist/module.json:

{
  "id": "settings-vault",
  "release": {
    "version": "0.2.1",
    "manifest": "https://github.com/vttforge/settings-vault/releases/download/v0.2.1/module.json",
    "notes": "https://github.com/vttforge/settings-vault/releases/tag/v0.2.1",
    "compatibility": { "minimum": "14", "verified": "14" }
  }
}

Both URLs answer 200 today.

Note on 0.2.1

This lands after 0.2.1 was cut, so that version is not registered by it. I filled that row in the form by hand and left it for you to save. From 0.3.0 on, nothing to fill.

The site keeps its own list of versions. A package with no entry there cannot
be installed from the site and offers nobody an update, so filling that form by
hand was the last manual step left in a release.

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 20ccd9e into main Sep 14, 2026
1 check passed
@fcsouza
fcsouza deleted the ci/foundry-release-api branch September 14, 2026 00:09
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