en/docs/development/ci/ci.md

Continuous Integration

A workflow defined at .forgejo/workflows/check.yaml performs several checks as defined in .justfile. This allows for the same commands to be run locally to similar effect.

Beware however, some differences in the CI environment:

• Git doesn't track empty directories, so any of those will be absent
• The current image, rust:slim, is based on Debian stable

Updating binaries fetched in CI

The CI workflow has some hardcoded versions for the following tooling:

Tool	Repository	Asset filename pattern
just	casey/just	just-1.45.0-x86_64-unknown-linux-musl.tar.gz
cargo-llvm-cov	taiki-e/cargo-llvm-cov	cargo-llvm-cov-x86_64-unknown-linux-gnu.tar.gz

These should be relatively recent to keep up with development environments, but don't really need to change often unless an interesting feature or security patch is available. When updates are desirable, they must be done manually so the actual changes behind each release can be properly reviewed and tested.

Determining latest release

A script is available in this directory to check for the last release on the tooling currently used. If a new release is available, it prints out some relevant information for deciding about an acting upon a CI workflow update.

To update the version, just edit the env section at the top of the workflow file with the new version tag and corresponding sha256sum value.

Getting tooling release data from the GitHub API

The GET endpoint /repos/{owner}/{repo}/releases can be used to list the existing releases.

curl -L \
  -H "Accept: application/json" \
  https://api.github.com/repos/OWNER/REPO/releases

This will return an array of release objects starting from the latest releases.

Relevant response fields in these objects include:

• .tag_name: Tag for specific, more detailed queries including assets (see below)
• .draft: Release was marked as draft. If true, don't use the release in CI.
• .prerelease: Release was marked as prerelease. If true, don't use the release in CI.
• .html_url: Sometimes includes notes with notable release changes.
• .body: Same as above, but directly in the response body.
• .created_at: Date the release was created (even if as a draft)
• .published_at: Date the release was published (e.g., from draft to published)

The GETendpoints /repos/{owner}/{repo}/releases/latest and /repos/{owner}/{repo}/releases/tags/{tag} can be used to get information on the very latest release and on a specific release as referenced by its tag.

curl -L \
  -H "Accept: application/json" \
  https://api.github.com/repos/OWNER/REPO/releases/latest

curl -L \
  -H "Accept: application/json" \
  https://api.github.com/repos/OWNER/REPO/releases/tags/TAG

For both of these endpoints, relevant fields include:

• .tag_name: From the latest endpoint, allows constructing a canonical URI for the release

• .assets_url: ?

• .html_url, .body, .draft, .prerelease: See above

• .assets: An array of asset objects

• .assets.[].name: File name, to be matched with the table above

• .assets.[].digest: Contains the sha256sum value

• .assets.[].url: A URL that returns this asset object alone

• .assets.[].browser_download_url Contains a download URL to fetch the actual asset

For the GitHub API reference, see https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28.

Notes

Some other notes relevant to modifying the CI workflow:

• $PATH in CI is /usr/local/cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin as of docker-rust commit c2c1f65, 2025-12-27