Deploy from CI/CD
Deploy from Forgejo and Gitea Actions
Forgejo and Gitea Actions read GitHub-style workflow files. The differences that matter here: the workflow lives in .forgejo/workflows/ (Gitea: .gitea/workflows/), the runner needs Docker, and the image goes to your instance's package registry, not GHCR.
Prerequisites: a runner with the label used in runs-on and access to a Docker daemon, a running Workload, its service instance id, the deploy token, and zaroz-deploy.sh as deploy/zaroz-deploy.sh.
Secrets and variables
In the repository (or organization) Settings > Actions:
| Name | Kind | Value |
|---|---|---|
ZAROZ_TOKEN | secret | the zaroz_... deploy token |
ZAROZ_SERVICE | variable | the service instance UUID |
REGISTRY_HOST | variable | your instance host, for example git.example.com |
REGISTRY_USERNAME | variable | the account that owns the packages |
REGISTRY_PASSWORD | secret | an access token with write:package (pushes) |
REGISTRY_PULL_TOKEN | secret | for a private package: an access token with read:package only. Zaroz uses this one to pull |
The workflow
Code
How it behaves:
- The image is
<host>/<owner>/<repo>:<12-char sha>. A package is private by default; make it public to deploy without a pull token. concurrencyqueues pushes, as in the other guides.- Zaroz pulls from inside its cluster, so the instance must be reachable from the internet over HTTPS with a valid certificate.
- If your runner has no
dockerbinary, build with Kaniko or Buildah in a job container instead; only theBuild and pushstep changes.
Roll back
Re-run the workflow for an older commit from the Actions tab, or run the script yourself with IMAGE=<host>/<owner>/<repo>:<old sha>.
Last modified on
