Add Forgejo compile and release workflows #2

Merged

drawblank merged 1 commit from add-forgejo-ci into master

2026-08-17 12:07:48 +00:00

drawblank commented

2026-08-17 12:05:33 +00:00

Contributor

Stacked on #1 — these workflows need pyproject.toml and uv.lock, so this targets modernize-packaging-and-fixes. Merge #1 first.

Modelled on games/engine: .forgejo/workflows/, dispatch-only triggers, actions/checkout@v4 + actions/upload-artifact@v3, and the compile → release split where release finds the newest successful compile run via the Forgejo API and promotes its artifact.

Runner choice

runs-on: alma10, not bryan. alma10 is the instance's general-purpose Linux runner — containers/engine-builder-linux's build-image.yaml and both engine release workflows use it bare, and slopenstein's bake-maps.yaml uses it with a container. bryan only ever appears alongside the engine-linux-builder image, and there is no Python image in the containers org.

Rather than adding one, the job installs uv in-step and lets uv provision its own interpreter. That satisfies requires-python = ">=3.12" without depending on what the runner's system Python happens to be.

Version handling

compile.yaml reads cstool.__version__ for the artifact name. release.yaml reads the version back out of the built wheel filename (cstool-1.0.7-py3-none-any.whl → v1.0.7), which ties the tag to the artifact actually being published rather than to whatever the release job checked out. The engine reads a root VERSION file; cstool has none, and adding one would duplicate a value pyproject.toml already resolves dynamically.

Release assets are the wheel and sdist directly — both are already distributable archives, so the engine's tar.gz wrapper adds nothing here.

Verified locally

Every compile.yaml step was run against this branch:

uv sync --locked        -> Resolved 14 packages
uv run basedpyright     -> 0 errors, 0 warnings, 0 notes
uv build                -> cstool-1.0.7-py3-none-any.whl, cstool-1.0.7.tar.gz
version from package    -> 1.0.7
wheel-filename parse    -> 1.0.7

Both YAML files parse.

Worth deciding

Dispatch-only follows house convention but makes the type check useless as a PR gate. Adding pull_request and push triggers to compile.yaml would make it actually gate merges. I kept the convention rather than deviating unasked.
No end-to-end regression coverage. A real cstool ./silicon.yaml run needs the ELSEPA distribution, which is not redistributable. Getting that into CI means baking it into a private image in the containers org and setting ELSEPA_DIR.
release.yaml filters on ref=refs/heads/master to match this repo's default branch (the engine uses main).

Stacked on #1 — these workflows need `pyproject.toml` and `uv.lock`, so this targets `modernize-packaging-and-fixes`. Merge #1 first. Modelled on `games/engine`: `.forgejo/workflows/`, dispatch-only triggers, `actions/checkout@v4` + `actions/upload-artifact@v3`, and the compile → release split where release finds the newest successful compile run via the Forgejo API and promotes its artifact. ## Runner choice `runs-on: alma10`, not `bryan`. `alma10` is the instance's general-purpose Linux runner — `containers/engine-builder-linux`'s `build-image.yaml` and both engine release workflows use it bare, and `slopenstein`'s `bake-maps.yaml` uses it with a container. `bryan` only ever appears alongside the `engine-linux-builder` image, and there is no Python image in the `containers` org. Rather than adding one, the job installs uv in-step and lets uv provision its own interpreter. That satisfies `requires-python = ">=3.12"` without depending on what the runner's system Python happens to be. ## Version handling `compile.yaml` reads `cstool.__version__` for the artifact name. `release.yaml` reads the version back out of the built wheel filename (`cstool-1.0.7-py3-none-any.whl` → `v1.0.7`), which ties the tag to the artifact actually being published rather than to whatever the release job checked out. The engine reads a root `VERSION` file; cstool has none, and adding one would duplicate a value `pyproject.toml` already resolves dynamically. Release assets are the wheel and sdist directly — both are already distributable archives, so the engine's tar.gz wrapper adds nothing here. ## Verified locally Every `compile.yaml` step was run against this branch: ``` uv sync --locked -> Resolved 14 packages uv run basedpyright -> 0 errors, 0 warnings, 0 notes uv build -> cstool-1.0.7-py3-none-any.whl, cstool-1.0.7.tar.gz version from package -> 1.0.7 wheel-filename parse -> 1.0.7 ``` Both YAML files parse. ## Worth deciding - **Dispatch-only follows house convention but makes the type check useless as a PR gate.** Adding `pull_request` and `push` triggers to `compile.yaml` would make it actually gate merges. I kept the convention rather than deviating unasked. - **No end-to-end regression coverage.** A real `cstool ./silicon.yaml` run needs the ELSEPA distribution, which is not redistributable. Getting that into CI means baking it into a private image in the `containers` org and setting `ELSEPA_DIR`. - **`release.yaml` filters on `ref=refs/heads/master`** to match this repo's default branch (the engine uses `main`).

drawblank added 1 commit

2026-08-17 12:05:33 +00:00

ci: add Forgejo compile and release workflows 7c99c3bd29

Follows the conventions in games/engine: .forgejo/workflows/, dispatch-only
triggers, actions/checkout@v4 and actions/upload-artifact@v3, and the split
where compile publishes an artifact that release later promotes.

Choices that differ from the engine, because cstool is pure Python:

- runs-on: alma10 rather than bryan. alma10 is the instance's
  general-purpose Linux runner (build-image.yaml and both engine release
  workflows use it bare); bryan only ever appears with the
  engine-linux-builder container, and there is no Python image in the
  containers org. uv is installed in-job and provisions its own
  interpreter, which satisfies requires-python >= 3.12 without depending
  on the runner's system Python.
- There is no compile/release pair per platform: the wheel is
  py3-none-any.
- Version comes from cstool.__version__ rather than a VERSION file, so it
  stays a single source of truth with pyproject's dynamic version. The
  release job reads it back out of the built wheel filename, which ties
  the tag to the artifact being published rather than to whatever the
  release job happened to check out.
- Release assets are the wheel and sdist directly, rather than a tar.gz
  wrapper, since both are already distributable archives.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

drawblank changed target branch from modernize-packaging-and-fixes to master

2026-08-17 12:07:40 +00:00

drawblank merged commit fca0c72149 into master

2026-08-17 12:07:48 +00:00

drawblank referenced this pull request from a commit

2026-08-17 12:07:49 +00:00

Merge pull request 'Add Forgejo compile and release workflows' (#2) from add-forgejo-ci into master