# 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/).