Files
Recruitment-HC/docs/image-build.md
T
2026-10-14 19:08:59 +07:00

102 lines
4.5 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 app is built; MySQL 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
```
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.
- Keep the Compose project name and volumes unchanged. Imports/migrations remain
explicit; follow [the deployment guide](deployment.md).
Compose retains the base file's `build` declaration 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/).