106 lines
4.7 KiB
Markdown
106 lines
4.7 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` |
|
|
| 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 |
|
|
|
|
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. The existing
|
|
`compose.yaml` still builds locally and remains usable without a registry.
|
|
|
|
To deploy the CI image instead, add a small override file in your server-side
|
|
Stack run directory, for example `compose.image.yaml`:
|
|
|
|
```yaml
|
|
services:
|
|
app:
|
|
image: gitea.cptckp.com/nurinda/recruitment-hc:latest
|
|
migrate:
|
|
image: gitea.cptckp.com/nurinda/recruitment-hc:latest
|
|
```
|
|
|
|
Prefer replacing `:latest` with the tested image digest (`@sha256:...` instead
|
|
of `:latest`).
|
|
Include both `compose.yaml` and `compose.image.yaml` in the Komodo Stack's Compose
|
|
file paths, in that order. Then:
|
|
|
|
- Disable **Run build** so Komodo does not build/tag a local image over the CI image.
|
|
- Enable **Auto pull** so the image is pulled before 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).
|
|
|
|
Compose retains both services' base `build` declarations in this simple override. Use
|
|
`docker compose ... up -d --no-build` for manual deployments of the CI image
|
|
(after registry login and `docker compose ... pull`); do **not** use `--build`.
|
|
Komodo's Auto pull supplies the image before `up`, with Run build disabled.
|
|
|
|
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/).
|