ci: push v<semver> tag so deploy-prod can pull it; point .env.prod at real prod paths #129

Merged

fastie81 merged 5 commits from fix/deploy-prod-tag-match into main 2026-09-05 22:06:30 +12:00

Conversation 1 Commits 5 Files changed 2 +68 -149

fastie81 commented 2026-09-05 21:13:29 +12:00

Owner

Copy link

Problem

deploy-prod sets APP_VERSION=${{ github.ref_name }} (e.g. v3.4.3) and pulls forgejo.scrat.co.nz/fastie81/honbu-manager:v3.4.3, but build-release only pushed bare semver (3.4.3) + latest via docker/metadata-action - so deploy-prod would always fail to find the v-prefixed tag. This CI path has never run end-to-end (verified: registry only contains test-* tags).

Fix

Add type=semver,pattern=v{{version}} to build-release metadata tags so the pushed image is also tagged v3.4.x, matching what deploy-prod pulls.

Also: point .env.prod BACKUP_PATH/CONTENT_PATH at the real prod host paths. deploy-prod scp-copies this .env.prod onto the prod node, so it must carry the absolute split-mount paths (else the backup-dir collision fix is silently reverted on the next prod deploy). Production has already been migrated to these paths (see #128 for the code/config split).

Note

Production is already running the fixed image (production-latest from #128, verified healthy, DB intact, backup now valid/non-recursive). This PR finishes making the automated v-tag -> build-release -> deploy-prod loop actually work.

## Problem deploy-prod sets APP_VERSION=${{ github.ref_name }} (e.g. v3.4.3) and pulls forgejo.scrat.co.nz/fastie81/honbu-manager:v3.4.3, but build-release only pushed bare semver (3.4.3) + latest via docker/metadata-action - so deploy-prod would always fail to find the v-prefixed tag. This CI path has never run end-to-end (verified: registry only contains test-* tags). ## Fix Add type=semver,pattern=v{{version}} to build-release metadata tags so the pushed image is also tagged v3.4.x, matching what deploy-prod pulls. Also: point .env.prod BACKUP_PATH/CONTENT_PATH at the real prod host paths. deploy-prod scp-copies this .env.prod onto the prod node, so it must carry the absolute split-mount paths (else the backup-dir collision fix is silently reverted on the next prod deploy). Production has already been migrated to these paths (see #128 for the code/config split). ## Note Production is already running the fixed image (production-latest from #128, verified healthy, DB intact, backup now valid/non-recursive). This PR finishes making the automated v-tag -> build-release -> deploy-prod loop actually work.

fastie81 added 1 commit 2026-09-05 21:13:31 +12:00

ci: push v<semver> tag so deploy-prod can pull it ... 60740dfd11

deploy-prod uses APP_VERSION=${{ github.ref_name }} (e.g. v3.4.3) to pull
the image, but build-release only pushed bare semver (3.4.3) + latest, so the
deploy would always fail to find v<ver>. Add type=semver,pattern=v{{version}}
to build-release so the pushed tag matches what deploy-prod pulls.

Also point .env.prod BACKUP_PATH/CONTENT_PATH at the real prod host paths (the
CI deploy scp-copies this file to the prod node), so the split-mounts fix is
applied on deploy rather than defaulting to relative ./paths.

fastie81 added 1 commit 2026-09-05 21:18:05 +12:00

ci: single-image build promoted test -> prod ... 65a3a74488

Requirement: build ONE image, test it, then deploy the same artifact to Test
then Prod.

- Replace separate build-test + build-release jobs with a single build job
  that builds and pushes one immutable image ci-<sha> (and, on a v<semver>
  tag, aliases it to <ver>, v<ver>, <major>.<minor>, latest).
- deploy-test (needs build) and deploy-prod (needs build + deploy-test) both
  consume that same image via needs.build.outputs.image_tag - so the exact
  image tested is what reaches production.
- deploy-prod binds to the -p honbu-manager-production compose project so the
  real data volumes are reused (avoids creating a parallel empty stack).
- Trigger on tags v* for the release path; deploy-test also runs on v-tags so
  the promoted image is exercised on the test node before prod.
- .env.prod: absolute BACKUP_PATH/CONTENT_PATH (prod host paths) so the split
  mount fix survives a CI deploy (CI scp-copies this file to prod).

fastie81 commented 2026-09-05 21:18:14 +12:00

Author

Owner

Copy link

Updated (commit 65a3a74): the pipeline now builds ONE image (ci-<sha>, aliased to v<ver>/<ver>/<major>.<minor>/latest on v-tags) and promotes that same artifact through deploy-test -> deploy-prod. deploy-test (needs: build) exercises it on the test node; deploy-prod (needs: build, deploy-test) pushes the identical image to prod on version tags. Also fixes the v-tag pull mismatch and binds -p honbu-manager-production so a prod deploy reuses the real data volumes. .env.prod carries absolute prod BACKUP_PATH/CONTENT_PATH so the #128 split-mount fix survives a CI deploy.

Updated (commit 65a3a74): the pipeline now builds ONE image (`ci-<sha>`, aliased to `v<ver>`/`<ver>`/`<major>.<minor>`/`latest` on v-tags) and promotes that same artifact through deploy-test -> deploy-prod. deploy-test (`needs: build`) exercises it on the test node; deploy-prod (`needs: build, deploy-test`) pushes the identical image to prod on version tags. Also fixes the v-tag pull mismatch and binds `-p honbu-manager-production` so a prod deploy reuses the real data volumes. `.env.prod` carries absolute prod BACKUP_PATH/CONTENT_PATH so the #128 split-mount fix survives a CI deploy.

fastie81 added 1 commit 2026-09-05 21:22:15 +12:00

ci: overlap image build with tests to cut wall-clock ... 926e618d35

Same tests, same deployment gates - the Docker image build now runs in
parallel with test/lint (build needs:[]), while deploy-test and deploy-prod
re-gate on test+lint+build (and deploy-prod also on deploy-test). This cuts
the critical path from test(after lint) then build (~3min + ~5min) to
max(test, build) (~5min) because the image build no longer waits for tests,
but tests still gate everything that is deployed. BuildKit inline layer cache
means pip/apt layers are also reused across runs.

fastie81 added 1 commit 2026-09-05 21:27:56 +12:00

ci: single push trigger plus expose podman socket to build job ... 43c5d54dfe

Drop the pull_request trigger - single-owner repo has no forks, so every PR
push fired both a push and a pull_request run, doubling each job.

Expose the runner's docker-compatible podman socket into the build job as
/var/run/docker.sock and set DOCKER_HOST so docker login and buildx can build.
This was a pre-existing gap on the Podman runner at 192.168.10.33 - build-test
had pushed 48 tags historically, but on the current podman label the job
container had no daemon socket, so buildx failed. Since deploy gates on build,
it had to reach a working daemon.

Same tests, same deployments - single trigger, no duplication, build reaches a daemon.

fastie81 added 1 commit 2026-09-05 21:54:12 +12:00

ci: prune old ci-* images (keep latest 5) via Forgejo packages API ... e1fcc240f2

Every build pushes an immutable ci-<sha> image; without retention the registry
accumulates one per push. After push, this step lists container versions via
the Forgejo packages API and deletes all but the 5 newest ci-* images (keeps
production-* and current). Uses REGISTRY_TOKEN (same token as docker login).

fastie81 merged commit ce0e52050c into main 2026-09-05 22:06:30 +12:00

fastie81 referenced this pull request from a commit 2026-09-05 22:06:33 +12:00

Merge pull request 'ci: push v<semver> tag so deploy-prod can pull it; point .env.prod at real prod paths' (#129) from fix/deploy-prod-tag-match into main

fastie81 referenced this pull request 2026-09-05 22:17:16 +12:00

ci: restore deploy-test and deploy-prod jobs (truncated in #129) #130

fastie81 referenced this pull request from a commit 2026-09-05 22:36:04 +12:00

Merge pull request 'ci: restore deploy-test and deploy-prod jobs (truncated in #129)' (#130) from fix/deploy-jobs-restore into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

architecture

Architecture change

  

backend

Backend (Python/Flask)

  

bug

Something is not working

  

ci

CI/CD pipeline

  

config

Configuration issue

  

database

Database related

  

docker

Docker/container related

  

documentation

Documentation

  

duplicate

This issue or pull request already exists

  

enhancement

New feature

  

frontend

Frontend (React/TypeScript)

  

help wanted

Need some help

  

invalid

Something is wrong

  

issue-25

Related to issue #25

  

issue-26

Related to issue #26

  

issue-42

Related to issue #42

  

issue-65

Related to issue #65

  

issue-67

Related to issue #67

  

issue-82

Related to issue #82

  

migrations

Database migrations

  

p0-critical

Critical priority - immediate fix needed

  

p1-high

High priority

  

p2-medium

Medium priority

  

p3-low

Low priority

  

performance

Performance issue

  

quality

Code quality

  

question

More information is needed

  

security

Security issue

  

state-management

Frontend state management

  

testing

Testing related

  

timezone

Timezone related

  

wontfix

This won't be fixed

No labels

architecture

backend

bug

ci

config

database

docker

documentation

duplicate

enhancement

frontend

help wanted

invalid

issue-25

issue-26

issue-42

issue-65

issue-67

issue-82

migrations

p0-critical

p1-high

p2-medium

p3-low

performance

quality

question

security

state-management

testing

timezone

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

fastie81/honbu-manager!129

No description provided.