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 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. 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.

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:

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.