Recruitment-HC/docs/image-build.md

Gitea Actions image build

Gitea discovers .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:

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:

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.

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:

docker pull gitea.cptckp.com/nurinda/recruitment-hc:latest

Verify a successful workflow run and available package before deploying it.

References: Gitea Actions compatibility and Gitea Container Registry.