Releasing

This page is for maintainers of weebo-forgejo. To install a release, see Install.

Versions come from the commit history: commits follow Conventional Commits (enforced by cocogitto on every commit), and cog bump --auto derives the next version from them.

What a release producesCopy Anchor Link

For a tag vX.Y.Z, publish.yml:

Each image is first built for amd64 and loaded locally, scanned by Grype (HIGH/CRITICAL fail the job, accepted findings are .grype.yaml's) and smoke-run; only then is the image pushed, and its pushed digest is scanned and smoke-run again before it's signed. latest/static only move when the tag is the highest version.

No arm64 image is published for now. Setting arm64: true in publish.yml adds one per variant (vX.Y.Z-arm64, vX.Y.Z-static-arm64), built on a native arm64 runner, scanned, smoke-run and signed the same way, but never a gate: a failure there leaves it out of the release.

Users verify all of it as described in Verify a release.

BumpingCopy Anchor Link

cog bump runs .hooks/bump-versions.sh, which writes the version into Cargo.toml ([workspace.package]), Cargo.lock and Chart.yaml (version and appVersion), commits, tags and updates CHANGELOG.md. Bumps are only allowed on main (branch_whitelist in cog.toml).

Locally (signed commits): the default when main requires signed commits:

cog bump --auto --dry-run   # shows the next version
cog bump --auto             # bump commit + tag, signed by your git config
git push origin main --follow-tags

The pushed tag triggers publish.yml, e2e gate included. Run the E2E workflow on main first if you want to know before tagging.

From GitHub: run the Release workflow manually. It runs the e2e on main first (so a failure leaves no tag behind), bumps with the workflow's token, pushes the commit and tag, then calls publish.yml for that tag without running the e2e a second time. This only works if main accepts the bot's unsigned commit.

To publish an existing tag again (e.g. after a registry hiccup), run publish.yml manually with that tag; it updates the existing GitHub Release instead of failing.

Before releasingCopy Anchor Link

The kind e2e runs locally too with a working container engine: task e2e (ENGINE=podman to build with podman; UPGRADE_FROM=none skips the upgrade test, UPGRADE_FROM=X.Y.Z picks the version to upgrade from). cert-manager and Forgejo are pinned in deploy/e2e/ (cert-manager's manifest by checksum): bump them there. For the live suites and coverage: task forgejo:container:start ENGINE=podman (writes .forgejo-test.env), then task coverage or task test:live-forgejo.

Changing the chartCopy Anchor Link

• The chart is built on weebo-operator-kit's library chart (weebo-operator-lib, a dependency pinned to the kit's version): templates/operator.yaml renders every resource but the CRDs, and templates/_params.tpl holds what is Forgejo's own (kinds, admitted kinds, WEEBO_FORGEJO_MAX_INFLIGHT, Forgejo egress, the Forgejo API alert). A change to a shared resource goes to the kit.
• The CRDs under deploy/charts/weebo-forgejo/templates/crds/ are generated by task recu (the kit's helm:crds) from deploy/crd/: never edit them.
• Every new value goes into values.yaml and values.schema.json (additionalProperties: false rejects unknown keys).
• task lint:helm (the kit's helm:lint) lints and renders the main value combinations, and checks that invalid ones are refused.
• task kit:sync TAG=vX.Y.Z moves the crates, the kit's tasks, the reusable workflows and the library chart to another kit release.

The documentation siteCopy Anchor Link

This site is published to GitHub Pages by docs-pages.yml on every push to main that touches docs/ or the CRDs, and can be re-run by hand. It's a static export (output: 'export'); the workflow sets DOCS_BASE_PATH to /weebo-forgejo for the project-site sub-path. Locally, task docs runs the dev server and task docs:build builds and lints it at the root.