[ARCHITECTURE] Eliminate git tag collision between cftunnels-service and portainer-automation + parametrize cftunnels deployment #150

New Issue

Archie · 2026-07-09T06:22:27Z

Archie commented

2026-07-09 06:22:27 +00:00

Problem Statement

Creating and pushing tag 0.28.2 fails because the tag already exists. This happens because both cftunnels-service and portainer-automation workflows create git tags on the same repo using the same semver namespace, but based on different triggers:

Workflow	Service	Runs On	Creates Tag
`test_image_build_push.yml`	cftunnels-service	Push to `test`	`0.x.y` (PATCH bump)
`prod_image_tag_promote.yaml`	cftunnels-service	Push to `main`	`0.x.y` (MINOR bump)
`portainer_automation_build_push.yml`	portainer-automation	Push to `test`/`main`	`0.x.y` (PATCH/MINOR bump)

When both workflows trigger on the same push event (e.g., merging to test), the first creates tag 0.28.2, then the second fails with fatal: tag '0.28.2' already exists.

Current Inventory

Tags on repo (gitea.hithomelabs.com/Hithomelabs/CFTunnels):

0.28.2, 0.28.1, 0.28.0, ... — cftunnels-service versions
pa-0.25.3, pa-0.25.2, pa-0.25.1 — portainer-automation versions (prefixed)
pa-pa-0.25.4 — double-prefixed bug

Note: PR #149 (for issue #139) drops the pa- prefix from portainer-automation tags, which will cause the collision described above once merged.

Desired Outcome

No tag collisions — portainer-automation and cftunnels-service must coexist peacefully
Parametrize cftunnels-service deployment — like portainer-automation (#139), merge test_image_build_push.yml + prod_image_tag_promote.yaml into one parameterized workflow
Remove duplication — clean up redundant code across the 3-4 workflow files

Architecture Decision Required

Please select one option below.

Option A: Service-Prefixed Tags (Recommended)

Re-introduce pa- prefix for portainer-automation tags. Each service tracks its own semver independently.

Service	Tag Pattern	Example
cftunnels-service	`0.x.y`	`0.28.2`
portainer-automation	`pa-0.x.y`	`pa-0.26.0`

Then merge test_image_build_push.yml + prod_image_tag_promote.yaml into a single parameterized workflow (like #139 did for portainer-automation).

Pros:

✅ Complete isolation — no tag collisions ever
✅ Both services keep independent semantic versioning
✅ Clear ownership — tag prefix tells you which service
✅ Minimal change — just add prefix back to the new param workflow in #149

Cons:

❌ Tag formats differ between services
❌ Reverts the "drop pa- prefix" decision from #139

Option B: Drop Git Tags for portainer-automation Entirely

portainer-automation doesn't need git tags — only docker image tags (test, prod, version). Use docker image tags as the sole version mechanism.

Keep git tags only for cftunnels-service (as it is today).

Pros:

✅ Zero collision risk
✅ Simplest change — just remove git tag/git push steps from portainer-automation workflow
✅ Tags only for meaningful releases (cftunnels is the main product)

Cons:

❌ portainer-automation loses git-based version history
❌ No way to checkout a specific portainer-automation version via git

Option C: Single Unified Version for the Entire Repo

One workflow, one version calculation, one tag. Both services are built from the same tag.

Pros:

✅ Single source of truth for versioning
✅ Both services always in sync
✅ No collision possible

Cons:

❌ Couples the two services — can't release one without the other
❌ Version bumps for a minor change in one service look like a full release
❌ Complex coupling logic

Option D: Tags Only on Main (Promotions), Not on Test

Only prod_image_tag_promote.yaml creates git tags (when merging to main). Test builds use timestamps or CI run IDs.

Pros:

✅ Fewer tags overall
✅ Tags represent actual releases, not dev builds
✅ Common CI/CD best practice

Cons:

❌ Changes existing dev workflow behavior
❌ No git version tracking for test/dev builds

@hitanshu Please select (A/B/C/D) or describe your preferred approach.

## Problem Statement Creating and pushing tag `0.28.2` fails because the tag already exists. This happens because **both** `cftunnels-service` and `portainer-automation` workflows create git tags on the **same repo** using the **same semver namespace**, but based on different triggers: | Workflow | Service | Runs On | Creates Tag | |----------|---------|---------|-------------| | `test_image_build_push.yml` | cftunnels-service | Push to `test` | `0.x.y` (PATCH bump) | | `prod_image_tag_promote.yaml` | cftunnels-service | Push to `main` | `0.x.y` (MINOR bump) | | `portainer_automation_build_push.yml` | portainer-automation | Push to `test`/`main` | `0.x.y` (PATCH/MINOR bump) | When both workflows trigger on the same push event (e.g., merging to `test`), the first creates tag `0.28.2`, then the second fails with `fatal: tag '0.28.2' already exists`. ## Current Inventory Tags on repo (`gitea.hithomelabs.com/Hithomelabs/CFTunnels`): - `0.28.2`, `0.28.1`, `0.28.0`, ... — cftunnels-service versions - `pa-0.25.3`, `pa-0.25.2`, `pa-0.25.1` — portainer-automation versions (prefixed) - `pa-pa-0.25.4` — double-prefixed bug **Note:** PR #149 (for issue #139) drops the `pa-` prefix from portainer-automation tags, which **will cause** the collision described above once merged. ## Desired Outcome 1. **No tag collisions** — portainer-automation and cftunnels-service must coexist peacefully 2. **Parametrize cftunnels-service deployment** — like portainer-automation (#139), merge `test_image_build_push.yml` + `prod_image_tag_promote.yaml` into one parameterized workflow 3. **Remove duplication** — clean up redundant code across the 3-4 workflow files ## Architecture Decision Required Please select one option below. --- ### Option A: Service-Prefixed Tags (Recommended) Re-introduce `pa-` prefix for portainer-automation tags. Each service tracks its own semver independently. | Service | Tag Pattern | Example | |---------|-------------|---------| | cftunnels-service | `0.x.y` | `0.28.2` | | portainer-automation | `pa-0.x.y` | `pa-0.26.0` | Then merge `test_image_build_push.yml` + `prod_image_tag_promote.yaml` into a single parameterized workflow (like #139 did for portainer-automation). **Pros:** - ✅ Complete isolation — no tag collisions ever - ✅ Both services keep independent semantic versioning - ✅ Clear ownership — tag prefix tells you which service - ✅ Minimal change — just add prefix back to the new param workflow in #149 **Cons:** - ❌ Tag formats differ between services - ❌ Reverts the "drop pa- prefix" decision from #139 --- ### Option B: Drop Git Tags for portainer-automation Entirely portainer-automation doesn't need git tags — only docker image tags (`test`, `prod`, version). Use docker image tags as the sole version mechanism. Keep git tags only for cftunnels-service (as it is today). **Pros:** - ✅ Zero collision risk - ✅ Simplest change — just remove `git tag`/`git push` steps from portainer-automation workflow - ✅ Tags only for meaningful releases (cftunnels is the main product) **Cons:** - ❌ portainer-automation loses git-based version history - ❌ No way to checkout a specific portainer-automation version via git --- ### Option C: Single Unified Version for the Entire Repo One workflow, one version calculation, one tag. Both services are built from the same tag. **Pros:** - ✅ Single source of truth for versioning - ✅ Both services always in sync - ✅ No collision possible **Cons:** - ❌ Couples the two services — can't release one without the other - ❌ Version bumps for a minor change in one service look like a full release - ❌ Complex coupling logic --- ### Option D: Tags Only on Main (Promotions), Not on Test Only `prod_image_tag_promote.yaml` creates git tags (when merging to `main`). Test builds use timestamps or CI run IDs. **Pros:** - ✅ Fewer tags overall - ✅ Tags represent actual releases, not dev builds - ✅ Common CI/CD best practice **Cons:** - ❌ Changes existing dev workflow behavior - ❌ No git version tracking for test/dev builds --- @hitanshu Please select (A/B/C/D) or describe your preferred approach.

Archie added the

CI/CD

needs-decision

labels 2026-07-09 06:22:35 +00:00

Dave referenced this issue from a commit

2026-07-09 06:30:43 +00:00

Hithomelabs/CFTunnels#150: Create unified cftunnels_build_push.yml with cf- prefix

Dave referenced this issue from a commit

2026-07-09 06:30:50 +00:00

Hithomelabs/CFTunnels#150: Add pa- prefix to portainer-automation tags and remove inputs block

Dave referenced this issue from a commit

2026-07-09 06:30:57 +00:00

Hithomelabs/CFTunnels#150: Delete test_image_build_push.yml (absorbed into cftunnels_build_push.yml)

Dave referenced this issue from a commit

2026-07-09 06:30:57 +00:00

Hithomelabs/CFTunnels#150: Delete prod_image_tag_promote.yaml (absorbed into cftunnels_build_push.yml)

Dave referenced this issue

2026-07-09 06:31:32 +00:00

[ISSUE-150] Fix tag collision: service-specific prefixes and unified cftunnels workflow #151

Dave commented

2026-07-09 06:31:38 +00:00

Implemented Option A (service-prefixed tags) via PR #151.

Changes

New: .gitea/workflows/cftunnels_build_push.yml — unified parameterized workflow with cf- prefix
Updated: .gitea/workflows/portainer_automation_build_push.yml — added pa- prefix, removed inputs block
Deleted: test_image_build_push.yml and prod_image_tag_promote.yaml (absorbed into new file)

Each service now uses its own tag prefix and tracks an independent semver sequence.

Implemented Option A (service-prefixed tags) via PR #151. ### Changes - **New:** `.gitea/workflows/cftunnels_build_push.yml` — unified parameterized workflow with `cf-` prefix - **Updated:** `.gitea/workflows/portainer_automation_build_push.yml` — added `pa-` prefix, removed inputs block - **Deleted:** `test_image_build_push.yml` and `prod_image_tag_promote.yaml` (absorbed into new file) Each service now uses its own tag prefix and tracks an independent semver sequence.

Dave referenced this issue from a commit

2026-07-09 06:45:07 +00:00

Hithomelabs/CFTunnels#150: Resolve merge conflict in portainer_automation_build_push.yml (keep pa- prefix with ASCII arrows)

Polly closed this issue

2026-07-09 17:24:12 +00:00

Polly commented

2026-07-09 17:24:30 +00:00

Closed ✅ — Fix implemented via PR #151 ([ISSUE-150] Fix tag collision: service-specific prefixes and unified cftunnels workflow) which:

Added cf- prefix for cftunnels-service tags
Added pa- prefix for portainer-automation tags
Unified test_image_build_push.yml + prod_image_tag_promote.yaml into cftunnels_build_push.yml
Carried to main via PR #152

The pa-pa-0.25.x double-prefix tags and stale tags from the collision still exist on the repo and can be cleaned up separately.

**Closed ✅** — Fix implemented via PR #151 ([ISSUE-150] Fix tag collision: service-specific prefixes and unified cftunnels workflow) which: - Added `cf-` prefix for cftunnels-service tags - Added `pa-` prefix for portainer-automation tags - Unified test_image_build_push.yml + prod_image_tag_promote.yaml into cftunnels_build_push.yml - Carried to `main` via PR #152 The `pa-pa-0.25.x` double-prefix tags and stale tags from the collision still exist on the repo and can be cleaned up separately.

Dave referenced this issue from a commit

2026-08-02 18:27:52 +00:00

Hithomelabs/CFTunnels#150: Add Spring Boot Actuator health check endpoints for portainer-automation

Linus referenced this issue

2026-08-02 18:30:46 +00:00

[ISSUE-150] Add Spring Boot Actuator Health Check Endpoints for portainer-automation Service #163

Dave referenced this issue

2026-08-02 18:31:19 +00:00

[ISSUE-150] Add Spring Boot Actuator Health Check Endpoints for portainer-automation Service #163

hitanshu referenced this issue

2026-08-02 19:48:32 +00:00

Hithomelabs/CFTunnels#150: Add Spring Boot Actuator health check endpoints for portainer-automation #164