105 lines
5.0 KiB
Markdown
105 lines
5.0 KiB
Markdown
# Gitea Actions image build
|
|
|
|
Gitea discovers [`.gitea/workflows/build-image.yaml`](../.gitea/workflows/build-image.yaml).
|
|
The workflow builds the root `Dockerfile` for the **Docker daemon's native
|
|
architecture** (typically `linux/amd64`) and publishes `:latest` to:
|
|
|
|
```text
|
|
gitea.cptckp.com/nurinda/recruitment-hc
|
|
```
|
|
|
|
Only the PHP/Apache image is built (used by both `app` and `migrate`); MySQL,
|
|
`db-init`, and phpMyAdmin retain their official images. Database exports and host credentials are excluded by `.dockerignore`.
|
|
|
|
## Setup
|
|
|
|
1. Enable **Actions** for the repository and ensure Gitea's package/container
|
|
registry is enabled.
|
|
2. Register an available runner with the **`ubuntu-latest`** label. Its job
|
|
environment needs Bash, Git, Node 20 support for these actions, Docker CLI,
|
|
and access to a Docker daemon with build support. No QEMU or separate Buildx
|
|
setup is required. Use an appropriately configured runner image or host-mode
|
|
runner; a bare Ubuntu job image without these tools is insufficient.
|
|
The runner must reach GitHub (pinned action downloads), Docker Hub (base images),
|
|
and `gitea.cptckp.com` over trusted HTTPS.
|
|
3. In **Repository Settings → Actions → Secrets**, add:
|
|
|
|
| Secret | Value |
|
|
| --- | --- |
|
|
| `REGISTRY_USERNAME` | Gitea username allowed to publish packages under `Nurinda` |
|
|
| `REGISTRY_TOKEN` | That user's personal access token with **Packages: Read & Write** |
|
|
|
|
Use a dedicated publishing account if possible. Its account/token must have
|
|
access to the organization and its packages. The built-in `GITEA_TOKEN` is
|
|
not used for registry publishing. Never put credentials in the workflow.
|
|
4. Commit and push these files to `main`, or run **Build and publish Docker
|
|
image** manually from the Actions tab.
|
|
|
|
Docker daemon access is highly privileged. Use a dedicated CI runner, not your
|
|
production Docker host. Only trusted changes merged/pushed to `main` are built;
|
|
pull requests do not trigger this workflow.
|
|
|
|
## Triggers and tags
|
|
|
|
| Event | Behavior |
|
|
| --- | --- |
|
|
| Push to `main` | Build and push `:latest`, unless only ignored paths changed |
|
|
| Manual run on `main` | Build and push `:latest` |
|
|
| Manual run on another branch or tag | Job skipped |
|
|
| Pull request or tag push | No workflow run |
|
|
|
|
Pushes changing only `docs/**`, `**/*.md`, `dev/**`, or `DB/**` skip the workflow.
|
|
Mixed changes still build if any file is outside those paths. Manual runs are
|
|
unaffected by path filters.
|
|
|
|
The workflow has three steps: checkout, registry login, and `docker build` /
|
|
`docker push`. It does not publish version/commit tags or multi-platform images.
|
|
Use a runner with the same architecture as your deployment server.
|
|
|
|
`latest` is mutable, and rebuilds can differ when upstream base images change.
|
|
Record the pushed image digest and deploy by digest for reproducibility/rollback.
|
|
Third-party actions are pinned to commit hashes with explicit GitHub URLs; review
|
|
and update those pins when upgrading actions.
|
|
|
|
## Use the published image with Komodo
|
|
|
|
The workflow only builds/publishes; it does **not** redeploy Komodo.
|
|
[`compose.yaml`](../compose.yaml) directly uses
|
|
`gitea.cptckp.com/nurinda/recruitment-hc:latest` for both `app` and `migrate`.
|
|
It has no local `build` declarations and requires no override file.
|
|
|
|
For reproducible deployments, replace the shared `app-image` YAML anchor's
|
|
`:latest` with the tested image digest (`@sha256:...`). Both services then use
|
|
that same pinned image.
|
|
|
|
Use only `compose.yaml` in the Komodo Stack's Compose file paths. Then:
|
|
|
|
- Disable **Run build**; Gitea Actions is responsible for building the image.
|
|
- Enable **Auto pull** so the image is pulled before deployment.
|
|
- Keep **Extra args** as `["--no-build"]` to explicitly enforce image-only deployment.
|
|
- Configure Komodo's Registry provider/account for `gitea.cptckp.com`; for private
|
|
packages, use a token with **Packages: Read** on an account allowed to pull them.
|
|
Keep this separate from the CI write token.
|
|
- Use the same tested image/digest for `app` and `migrate`.
|
|
- Keep the Compose project name and volumes unchanged. Set `DB_INIT_SQL_PATH` to
|
|
a trusted dump on the Docker host. Initialization/migrations run automatically;
|
|
follow [the deployment guide](deployment.md).
|
|
|
|
For manual deployments, run `docker compose ... pull` followed by
|
|
`docker compose ... up -d --no-build` after registry login; do **not** use `--build`.
|
|
Komodo's Auto pull supplies the image before `up`, with Run build disabled and
|
|
`--no-build` set. The `recruitment-hc` entry in `komodo-sync/resources/stacks/web.toml`
|
|
uses this single-file configuration. Push the application changes and wait for
|
|
Gitea Actions to publish successfully before applying that Stack configuration.
|
|
|
|
For example, after configuring registry authentication on the server:
|
|
|
|
```sh
|
|
docker pull gitea.cptckp.com/nurinda/recruitment-hc:latest
|
|
```
|
|
|
|
Verify a successful workflow run and available package before deploying it.
|
|
|
|
References: [Gitea Actions compatibility](https://docs.gitea.com/usage/actions/comparison/)
|
|
and [Gitea Container Registry](https://docs.gitea.com/usage/packages/container/).
|