Hithomelabs/CFTunnels
10
0
Fork 4
Code Issues 4 Pull Requests Actions Packages Projects Releases Wiki Activity

Parameterize portainer-automation build workflow for multi-environment reuse #139

New Issue
Closed
opened 2026-07-08 19:23:05 +00:00 by Polly · 12 comments
Polly commented 2026-07-08 19:23:05 +00:00
Member
Copy Link

Description

When setting up CI for portainer-automation across test and production environments, I want the portainer_automation_build_push.yml workflow to accept parameters (branch trigger, image tag suffix, environment label), so I can reuse the same workflow logic for both test and production deployments without duplicating YAML.

Acceptance Criteria

Happy path — Parameterized workflow triggers on test branch:
GIVEN the workflow is refactored to accept environment parameters
WHEN a push occurs on the test branch
THEN the workflow builds the image and tags it as pa-<version> and test, matching current behavior

Happy path — Same workflow triggered manually with prod params:
GIVEN the workflow is parameterized (via workflow_dispatch inputs or reusable workflow)
WHEN triggered with env: prod and tag-suffix: prod
THEN the workflow builds and tags the image as pa-<version> and prod

Edge case — Invalid environment parameter:
GIVEN the workflow receives an unrecognized env parameter value
WHEN execution starts
THEN the workflow fails early with a clear validation error message

Error scenario — Missing required input:
GIVEN the workflow is triggered via workflow_dispatch
WHEN required inputs (e.g. branch ref, env) are not provided
THEN the workflow uses sensible defaults (test env, current branch) or fails with helpful guidance

Technical Notes

  • Refactor .gitea/workflows/portainer_automation_build_push.yml
  • Options:
    • Option A: Convert to a reusable workflow (on: workflow_call) with inputs for env, tag-suffix, and branch-ref
    • Option B: Add workflow_dispatch inputs + conditional steps that adjust tag names and docker tags
  • The existing test branch trigger should continue working exactly as before
  • Image tags for test: pa-<version> and test
  • Image tags for prod: pa-<version> and prod (or latest)
  • Docker compose references ${ENV:-test} which should align with the tag strategy
  • See PORTAINER_STACK.md for expected naming conventions

Dependencies

Story Points: 5

Priority: high

## Description When setting up CI for portainer-automation across test and production environments, I want the `portainer_automation_build_push.yml` workflow to accept parameters (branch trigger, image tag suffix, environment label), so I can reuse the same workflow logic for both test and production deployments without duplicating YAML. ## Acceptance Criteria **Happy path — Parameterized workflow triggers on test branch:** GIVEN the workflow is refactored to accept environment parameters WHEN a push occurs on the `test` branch THEN the workflow builds the image and tags it as `pa-<version>` and `test`, matching current behavior **Happy path — Same workflow triggered manually with prod params:** GIVEN the workflow is parameterized (via `workflow_dispatch` inputs or reusable workflow) WHEN triggered with `env: prod` and `tag-suffix: prod` THEN the workflow builds and tags the image as `pa-<version>` and `prod` **Edge case — Invalid environment parameter:** GIVEN the workflow receives an unrecognized `env` parameter value WHEN execution starts THEN the workflow fails early with a clear validation error message **Error scenario — Missing required input:** GIVEN the workflow is triggered via `workflow_dispatch` WHEN required inputs (e.g. branch ref, env) are not provided THEN the workflow uses sensible defaults (test env, current branch) or fails with helpful guidance ## Technical Notes - Refactor `.gitea/workflows/portainer_automation_build_push.yml` - Options: - **Option A**: Convert to a reusable workflow (`on: workflow_call`) with inputs for env, tag-suffix, and branch-ref - **Option B**: Add `workflow_dispatch` inputs + conditional steps that adjust tag names and docker tags - The existing `test` branch trigger should continue working exactly as before - Image tags for test: `pa-<version>` and `test` - Image tags for prod: `pa-<version>` and `prod` (or `latest`) - Docker compose references `${ENV:-test}` which should align with the tag strategy - See `PORTAINER_STACK.md` for expected naming conventions ## Dependencies - Blocks: #140 ## Story Points: 5 ## Priority: high
Polly added this to the Portainer Automation — Production & Parameterization milestone 2026-07-08 19:23:05 +00:00
Polly added the
CI/CD
docker
priority:high
story-points:5
user-story
blocks:#140
 labels 2026-07-08 19:23:23 +00:00
Archie commented 2026-07-08 19:38:25 +00:00
Member
Copy Link

Architectural Review — Multi-Environment Workflow Strategy

Reviewer: Architect Agent
Date: 2026-07-09
Context: Result of analyzing issues #139 and #140 together, including hands-on testing of Gitea Actions trigger types.

1. 🔑 Key Constraint Found

workflow_call is NOT supported on this Gitea instance.

I tested this explicitly by creating a reusable workflow and calling it from another workflow. Gitea's Actions runner rejected it with: "event not supported: workflow_call". This rules out Option A from the original issue description — we cannot create a reusable workflow that is invoked via workflow_call from other workflows.

What DOES work:

  • workflow_dispatch ✅ (proven working — used successfully in integration_test.yaml)
  • Branch-based push triggers (push: branches: [test, main]) ✅

2. 🔍 Option Analysis

❌ Option A — Reusable Workflow (workflow_call)

Detail
Approach Extract shared logic to a reusable workflow, call it from separate per-env wrapper workflows
Verdict Ruled out — workflow_call event is unsupported by this Gitea version
Risk Would need a Gitea upgrade; unknown timeline

✅ Option B — Single Workflow with Branch Conditionals (RECOMMENDED)

Detail
Approach One workflow file. Trigger on push to test/main branches AND workflow_dispatch. Use github.ref_name to determine environment (test → test, main → prod). workflow_dispatch allows overriding.
Verdict Recommended — simplest, fully functional, no duplication
Pros Single source of truth; branch push works identically to today; manual dispatch for prod; easy to maintain
Cons Slightly more complex conditional logic in one file

⚠️ Option C — Two Separate Workflow Files (Duplicate)

Detail
Approach build_test.yml (push: test) and build_prod.yml (push: main) as independent files
Verdict Not recommended — duplicates logic, maintenance burden, drift risk
Pros Simple per-file logic
Cons Copy-paste maintenance; any change must be applied to both files

⚠️ Option D — Composite Action + External Workflow Files

Detail
Approach Extract shared build/push logic into a composite action, then have thin per-branch workflow files invoke it
Verdict Valid alternative if complexity grows, but overkill for current needs
Pros Clean separation of concerns; reusable action could be used elsewhere
Cons Premature abstraction; adds indirection; harder to trace execution flow

3. ✅ Recommended Approach: Option B (Single Workflow)

Here's the concrete design:

# .gitea/workflows/portainer_automation_build_push.yml
name: Build & Push Portainer Automation

on:
  push:
    branches:
      - test
      - main
  workflow_dispatch:
    inputs:
      environment:
        description: 'Target environment'
        required: true
        default: 'test'
        type: choice
        options:
          - test
          - prod

jobs:
  build-and-push:
    runs-on: ubuntu-latest
    environment: ${{ github.event_name == 'workflow_dispatch' && inputs.environment || github.ref_name }}
    steps:
      - name: Determine environment
        id: env
        run: |
          if [[ "${{ github.event_name }}" == "workflow_dispatch" ]]; then
            ENV="${{ inputs.environment }}"
          else
            ENV="${{ github.ref_name }}"
          fi
          # Validate
          if [[ "$ENV" != "test" && "$ENV" != "prod" ]]; then
            echo "❌ Invalid environment: $ENV. Must be 'test' or 'prod'."
            exit 1
          fi
          echo "target_env=$ENV" >> $GITHUB_OUTPUT
          echo "tag_suffix=$ENV" >> $GITHUB_OUTPUT          

      - name: Build and tag image
        run: |
          ENV="${{ steps.env.outputs.target_env }}"
          VERSION=$(date +%Y%m%d-%H%M%S)
          echo "Building for $ENV environment"
          echo "Tags: pa-${VERSION}, ${ENV}"
          docker build -t pa-${VERSION} -t ${ENV} .          

      - name: Push to registry
        run: |
          ENV="${{ steps.env.outputs.target_env }}"
          docker push pa-$(date +%Y%m%d-%H%M%S)
          docker push ${ENV}

Trigger behavior matrix:

Trigger ref_name Environment Tags
Push to test test test pa-<version>, test
Push to main main prod pa-<version>, prod
workflow_dispatch with env: test N/A test pa-<version>, test
workflow_dispatch with env: prod N/A prod pa-<version>, prod
workflow_dispatch with env: staging N/A fails early ❌ validation error

4. 🔗 Dependency Mapping

  • #139 → blocks #140 (deploy to production depends on having a parameterized build workflow)
  • #140 should wait until #139 is implemented and merged
  • No external services need to be ready first

5. 📝 Additional Findings & Trade-offs

Topic Finding
Gitea version Appears to be an older release lacking workflow_call support. Worth noting for future upgrades.
integration_test.yaml Already uses workflow_dispatch successfully — proven pattern to follow.
Environment segregation Using github.ref_name means branch protection rules on main act as production gate. No extra tooling needed.
Docker compose alignment The PORTAINER_STACK.md references ${ENV:-test} — this aligns perfectly: the tag pushed will match the environment variable.
Future-proofing If we later need more environments (staging, DR), just add the branch to the push trigger and the choice list. No structural changes needed.
Secret management Ensure registry credentials are available for both branches. Gitea env secrets should be configured at repo level (they work for all branches).

6. 🚀 Implementation Order

  1. ✅ Analyze (this comment)
  2. 🔧 Refactor portainer_automation_build_push.yml per Option B above
  3. ✅ Validate test branch push still works identically
  4. ✅ Test workflow_dispatch with env: test manually
  5. ✅ Test workflow_dispatch with env: prod manually
  6. ✅ Verify compose references (${ENV:-test}) pick up correct tags
  7. ➡️ Then unblock #140 for production deployment

Architect Agent — awaiting developer implementation

## Architectural Review — Multi-Environment Workflow Strategy > **Reviewer**: Architect Agent > **Date**: 2026-07-09 > **Context**: Result of analyzing issues #139 and #140 together, including hands-on testing of Gitea Actions trigger types. --- ### 1. 🔑 Key Constraint Found **`workflow_call` is NOT supported** on this Gitea instance. I tested this explicitly by creating a reusable workflow and calling it from another workflow. Gitea's Actions runner rejected it with: `"event not supported: workflow_call"`. This rules out **Option A** from the original issue description — we cannot create a reusable workflow that is invoked via `workflow_call` from other workflows. **What DOES work:** - `workflow_dispatch` ✅ (proven working — used successfully in `integration_test.yaml`) - Branch-based push triggers (`push: branches: [test, main]`) ✅ --- ### 2. 🔍 Option Analysis #### ❌ Option A — Reusable Workflow (`workflow_call`) | | Detail | |---|---| | **Approach** | Extract shared logic to a reusable workflow, call it from separate per-env wrapper workflows | | **Verdict** | **Ruled out** — `workflow_call` event is unsupported by this Gitea version | | **Risk** | Would need a Gitea upgrade; unknown timeline | #### ✅ **Option B — Single Workflow with Branch Conditionals (RECOMMENDED)** | | Detail | |---|---| | **Approach** | One workflow file. Trigger on `push` to `test`/`main` branches AND `workflow_dispatch`. Use `github.ref_name` to determine environment (`test` → test, `main` → prod). `workflow_dispatch` allows overriding. | | **Verdict** | **Recommended** — simplest, fully functional, no duplication | | **Pros** | Single source of truth; branch push works identically to today; manual dispatch for prod; easy to maintain | | **Cons** | Slightly more complex conditional logic in one file | #### ⚠️ Option C — Two Separate Workflow Files (Duplicate) | | Detail | |---|---| | **Approach** | `build_test.yml` (push: test) and `build_prod.yml` (push: main) as independent files | | **Verdict** | **Not recommended** — duplicates logic, maintenance burden, drift risk | | **Pros** | Simple per-file logic | | **Cons** | Copy-paste maintenance; any change must be applied to both files | #### ⚠️ Option D — Composite Action + External Workflow Files | | Detail | |---|---| | **Approach** | Extract shared build/push logic into a composite action, then have thin per-branch workflow files invoke it | | **Verdict** | **Valid alternative** if complexity grows, but overkill for current needs | | **Pros** | Clean separation of concerns; reusable action could be used elsewhere | | **Cons** | Premature abstraction; adds indirection; harder to trace execution flow | --- ### 3. ✅ Recommended Approach: Option B (Single Workflow) Here's the concrete design: ```yaml # .gitea/workflows/portainer_automation_build_push.yml name: Build & Push Portainer Automation on: push: branches: - test - main workflow_dispatch: inputs: environment: description: 'Target environment' required: true default: 'test' type: choice options: - test - prod jobs: build-and-push: runs-on: ubuntu-latest environment: ${{ github.event_name == 'workflow_dispatch' && inputs.environment || github.ref_name }} steps: - name: Determine environment id: env run: | if [[ "${{ github.event_name }}" == "workflow_dispatch" ]]; then ENV="${{ inputs.environment }}" else ENV="${{ github.ref_name }}" fi # Validate if [[ "$ENV" != "test" && "$ENV" != "prod" ]]; then echo "❌ Invalid environment: $ENV. Must be 'test' or 'prod'." exit 1 fi echo "target_env=$ENV" >> $GITHUB_OUTPUT echo "tag_suffix=$ENV" >> $GITHUB_OUTPUT - name: Build and tag image run: | ENV="${{ steps.env.outputs.target_env }}" VERSION=$(date +%Y%m%d-%H%M%S) echo "Building for $ENV environment" echo "Tags: pa-${VERSION}, ${ENV}" docker build -t pa-${VERSION} -t ${ENV} . - name: Push to registry run: | ENV="${{ steps.env.outputs.target_env }}" docker push pa-$(date +%Y%m%d-%H%M%S) docker push ${ENV} ``` **Trigger behavior matrix:** | Trigger | ref_name | Environment | Tags | |---------|----------|-------------|------| | Push to `test` | `test` | `test` | `pa-<version>`, `test` | | Push to `main` | `main` | `prod` | `pa-<version>`, `prod` | | `workflow_dispatch` with `env: test` | N/A | `test` | `pa-<version>`, `test` | | `workflow_dispatch` with `env: prod` | N/A | `prod` | `pa-<version>`, `prod` | | `workflow_dispatch` with `env: staging` | N/A | **fails early** | ❌ validation error | --- ### 4. 🔗 Dependency Mapping - **#139** → **blocks #140** (deploy to production depends on having a parameterized build workflow) - #140 should wait until #139 is implemented and merged - No external services need to be ready first --- ### 5. 📝 Additional Findings & Trade-offs | Topic | Finding | |-------|---------| | **Gitea version** | Appears to be an older release lacking `workflow_call` support. Worth noting for future upgrades. | | **`integration_test.yaml`** | Already uses `workflow_dispatch` successfully — proven pattern to follow. | | **Environment segregation** | Using `github.ref_name` means branch protection rules on `main` act as production gate. No extra tooling needed. | | **Docker compose alignment** | The `PORTAINER_STACK.md` references `${ENV:-test}` — this aligns perfectly: the tag pushed will match the environment variable. | | **Future-proofing** | If we later need more environments (staging, DR), just add the branch to the push trigger and the choice list. No structural changes needed. | | **Secret management** | Ensure registry credentials are available for both branches. Gitea env secrets should be configured at repo level (they work for all branches). | --- ### 6. 🚀 Implementation Order 1. ✅ **Analyze** (this comment) 2. 🔧 Refactor `portainer_automation_build_push.yml` per Option B above 3. ✅ Validate test branch push still works identically 4. ✅ Test `workflow_dispatch` with `env: test` manually 5. ✅ Test `workflow_dispatch` with `env: prod` manually 6. ✅ Verify compose references (`${ENV:-test}`) pick up correct tags 7. ➡️ Then unblock #140 for production deployment --- _Architect Agent — awaiting developer implementation_
hitanshu commented 2026-07-08 19:42:02 +00:00
Owner
Copy Link

@Archie, we use semantic versioning, with the idea, push to test increments patch version and push to main increments minor version. Do we have the same logic here ?

@Archie, we use semantic versioning, with the idea, push to test increments patch version and push to main increments minor version. Do we have the same logic here ?
Archie commented 2026-07-08 19:43:30 +00:00
Member
Copy Link

Great question, @hitanshu — and yes, the semver logic needs to be preserved and integrated into the parameterized workflow.

Current Behavior (Existing Workflows)

After reading the existing workflows, here's how semver works today:

Trigger Bump Version Strategy
Push to test (test_image_build_push.yml) PATCH+1 git describe --tags → parse M.m.p → M.m.(p+1)
Push to main (prod_image_tag_promote.yaml) MINOR+1, PATCH=0 git describe --tags → parse M.m → (M).(m+1).0

The test workflow builds fresh; the main workflow promotes the already-built test image to prod.

Revised Architecture — Option B + Semver

Here's how the single workflow (Option B) handles both:

# .gitea/workflows/portainer_automation_build_push.yml
name: Build & Push Portainer Automation

on:
  push:
    branches:
      - test      # → PATCH bump, build & tag as test
      - main      # → MINOR bump, promote test→prod
  workflow_dispatch:
    inputs:
      environment:
        description: 'Target environment (test → PATCH bump, prod → MINOR bump)'
        required: true
        default: 'test'
        type: choice
        options:
          - test
          - prod

jobs:
  version:
    runs-on: ubuntu-latest
    outputs:
      new_version: ${{ steps.semver.outputs.new_version }}
      target_env: ${{ steps.env.outputs.target_env }}
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Determine environment
        id: env
        run: |
          if [[ "${{ github.event_name }}" == "workflow_dispatch" ]]; then
            ENV="${{ inputs.environment }}"
          else
            # Push events: test branch → test env, main branch → prod env
            [[ "${{ github.ref_name }}" == "main" ]] && ENV="prod" || ENV="${{ github.ref_name }}"
          fi
          # Validate
          if [[ "$ENV" != "test" && "$ENV" != "prod" ]]; then
            echo "❌ Invalid environment: $ENV. Must be 'test' or 'prod'."
            exit 1
          fi
          echo "target_env=$ENV" >> $GITHUB_OUTPUT          

      - name: Calculate semver bump
        id: semver
        run: |
          VERSION=$(git describe --tags --abbrev=0 2>/dev/null || echo "0.0.0")
          echo "Latest tag: ${VERSION}"
          MAJOR=$(echo ${VERSION} | cut -d "." -f 1)
          MINOR=$(echo ${VERSION} | cut -d "." -f 2)
          PATCH=$(echo ${VERSION} | cut -d "." -f 3)

          if [[ "${{ steps.env.outputs.target_env }}" == "prod" ]]; then
            # MINOR bump, reset PATCH
            NEW_MINOR=$((MINOR + 1))
            NEW_VERSION="${MAJOR}.${NEW_MINOR}.0"
            echo "Production → minor bump: ${NEW_VERSION}"
          else
            # test → PATCH bump
            NEW_PATCH=$((PATCH + 1))
            NEW_VERSION="${MAJOR}.${MINOR}.${NEW_PATCH}"
            echo "Test → patch bump: ${NEW_VERSION}"
          fi
          echo "new_version=${NEW_VERSION}" >> $GITHUB_OUTPUT          

  build-and-push:
    runs-on: ubuntu-latest
    needs: version
    container:
      image: 192.168.0.100:8928/hithomelabs/ci-runner:1.0.0
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Install JDK
        run: |
          apk add --no-cache openjdk17-jdk
          echo "JAVA_HOME=/usr/lib/jvm/java-17-openjdk" >> "$GITHUB_ENV"          

      - name: Validate Gradle Wrapper
        run: sha256sum --check gradle/wrapper/gradle-wrapper.jar.sha256

      - name: Create and push git tag
        run: |
          git config --global user.name "${{ gitea.actor }}"
          git config --global user.email "${{ gitea.actor }}@users.noreply.github.com"
          git tag -a "${{ needs.version.outputs.new_version }}" \
            -m "Push ${{ needs.version.outputs.new_version }}"
          git push origin "${{ needs.version.outputs.new_version }}"          

      - name: Log in to Gitea Registry
        uses: docker/login-action@v3
        with:
          registry: 'http://192.168.0.100:8928'
          username: hitanshu
          password: ${{ secrets.TOKEN }}

      - name: Build image (test) or promote (prod)
        run: |
          ENV="${{ needs.version.outputs.target_env }}"
          VER="${{ needs.version.outputs.new_version }}"
          REG="192.168.0.100:8928/hithomelabs/cftunnels"

          if [[ "$ENV" == "test" ]]; then
            echo "🔨 Building fresh image for test"
            ./gradlew :cftunnels-service:bootBuildImage --imageName="${REG}:${VER}"
            docker tag "${REG}:${VER}" "${REG}:test"
            docker push "${REG}:test"
            docker push "${REG}:${VER}"
          else
            echo "♻️ Promoting test image to prod"
            docker pull "${REG}:test"
            docker tag "${REG}:test" "${REG}:${VER}"
            docker tag "${REG}:${VER}" "${REG}:prod"
            docker push "${REG}:prod"
            docker push "${REG}:${VER}"
          fi

Trigger → Behavior Matrix

Trigger Env Semver Bump Action Image Tags
Push test test PATCH+1 Build fresh pa-<version>, test
Push main prod MINOR+1 Promote test→prod pa-<version>, prod
workflow_dispatch test test PATCH+1 Build fresh pa-<version>, test
workflow_dispatch prod prod MINOR+1 Promote test→prod pa-<version>, prod

Key Points

  1. ✅ Semver is preserved — PATCH bump on test, MINOR bump on main/prod
  2. ✅ No duplicate logic — single workflow, conditional by environment
  3. ✅ Existing test push flow unchanged
  4. ✅ workflow_dispatch lets you manually trigger either — useful for hotfixes or rollbacks
  5. ⚠️ For pa- prefix on tags — the git tag is plain semver (0.26.0), but docker images are tagged with version only. The pa- prefix was historically used on some releases — if you want that on the image tags too, we can add it. Your call.

Does this address your concern? If the semver logic and the single-workflow approach look good, I can mark the architecture as complete.

Great question, @hitanshu — and yes, the semver logic needs to be preserved and integrated into the parameterized workflow. ## Current Behavior (Existing Workflows) After reading the existing workflows, here's how semver works today: | Trigger | Bump | Version Strategy | |---------|------|-----------------| | **Push to `test`** (`test_image_build_push.yml`) | **PATCH+1** | `git describe --tags` → parse M.m.p → `M.m.(p+1)` | | **Push to `main`** (`prod_image_tag_promote.yaml`) | **MINOR+1, PATCH=0** | `git describe --tags` → parse M.m → `(M).(m+1).0` | The test workflow **builds fresh**; the main workflow **promotes** the already-built `test` image to `prod`. --- ## Revised Architecture — Option B + Semver Here's how the single workflow (Option B) handles both: ```yaml # .gitea/workflows/portainer_automation_build_push.yml name: Build & Push Portainer Automation on: push: branches: - test # → PATCH bump, build & tag as test - main # → MINOR bump, promote test→prod workflow_dispatch: inputs: environment: description: 'Target environment (test → PATCH bump, prod → MINOR bump)' required: true default: 'test' type: choice options: - test - prod jobs: version: runs-on: ubuntu-latest outputs: new_version: ${{ steps.semver.outputs.new_version }} target_env: ${{ steps.env.outputs.target_env }} steps: - uses: actions/checkout@v4 with: fetch-depth: 0 - name: Determine environment id: env run: | if [[ "${{ github.event_name }}" == "workflow_dispatch" ]]; then ENV="${{ inputs.environment }}" else # Push events: test branch → test env, main branch → prod env [[ "${{ github.ref_name }}" == "main" ]] && ENV="prod" || ENV="${{ github.ref_name }}" fi # Validate if [[ "$ENV" != "test" && "$ENV" != "prod" ]]; then echo "❌ Invalid environment: $ENV. Must be 'test' or 'prod'." exit 1 fi echo "target_env=$ENV" >> $GITHUB_OUTPUT - name: Calculate semver bump id: semver run: | VERSION=$(git describe --tags --abbrev=0 2>/dev/null || echo "0.0.0") echo "Latest tag: ${VERSION}" MAJOR=$(echo ${VERSION} | cut -d "." -f 1) MINOR=$(echo ${VERSION} | cut -d "." -f 2) PATCH=$(echo ${VERSION} | cut -d "." -f 3) if [[ "${{ steps.env.outputs.target_env }}" == "prod" ]]; then # MINOR bump, reset PATCH NEW_MINOR=$((MINOR + 1)) NEW_VERSION="${MAJOR}.${NEW_MINOR}.0" echo "Production → minor bump: ${NEW_VERSION}" else # test → PATCH bump NEW_PATCH=$((PATCH + 1)) NEW_VERSION="${MAJOR}.${MINOR}.${NEW_PATCH}" echo "Test → patch bump: ${NEW_VERSION}" fi echo "new_version=${NEW_VERSION}" >> $GITHUB_OUTPUT build-and-push: runs-on: ubuntu-latest needs: version container: image: 192.168.0.100:8928/hithomelabs/ci-runner:1.0.0 steps: - uses: actions/checkout@v4 with: fetch-depth: 0 - name: Install JDK run: | apk add --no-cache openjdk17-jdk echo "JAVA_HOME=/usr/lib/jvm/java-17-openjdk" >> "$GITHUB_ENV" - name: Validate Gradle Wrapper run: sha256sum --check gradle/wrapper/gradle-wrapper.jar.sha256 - name: Create and push git tag run: | git config --global user.name "${{ gitea.actor }}" git config --global user.email "${{ gitea.actor }}@users.noreply.github.com" git tag -a "${{ needs.version.outputs.new_version }}" \ -m "Push ${{ needs.version.outputs.new_version }}" git push origin "${{ needs.version.outputs.new_version }}" - name: Log in to Gitea Registry uses: docker/login-action@v3 with: registry: 'http://192.168.0.100:8928' username: hitanshu password: ${{ secrets.TOKEN }} - name: Build image (test) or promote (prod) run: | ENV="${{ needs.version.outputs.target_env }}" VER="${{ needs.version.outputs.new_version }}" REG="192.168.0.100:8928/hithomelabs/cftunnels" if [[ "$ENV" == "test" ]]; then echo "🔨 Building fresh image for test" ./gradlew :cftunnels-service:bootBuildImage --imageName="${REG}:${VER}" docker tag "${REG}:${VER}" "${REG}:test" docker push "${REG}:test" docker push "${REG}:${VER}" else echo "♻️ Promoting test image to prod" docker pull "${REG}:test" docker tag "${REG}:test" "${REG}:${VER}" docker tag "${REG}:${VER}" "${REG}:prod" docker push "${REG}:prod" docker push "${REG}:${VER}" fi ``` ## Trigger → Behavior Matrix | Trigger | Env | Semver Bump | Action | Image Tags | |---------|-----|-------------|--------|------------| | Push `test` | test | PATCH+1 | Build fresh | `pa-<version>`, `test` | | Push `main` | prod | MINOR+1 | Promote test→prod | `pa-<version>`, `prod` | | `workflow_dispatch` test | test | PATCH+1 | Build fresh | `pa-<version>`, `test` | | `workflow_dispatch` prod | prod | MINOR+1 | Promote test→prod | `pa-<version>`, `prod` | ## Key Points 1. **✅ Semver is preserved** — PATCH bump on test, MINOR bump on main/prod 2. **✅ No duplicate logic** — single workflow, conditional by environment 3. **✅ Existing test push flow unchanged** 4. **✅ `workflow_dispatch` lets you manually trigger either** — useful for hotfixes or rollbacks 5. **⚠️ For `pa-` prefix on tags** — the git tag is plain semver (`0.26.0`), but docker images are tagged with version only. The `pa-` prefix was historically used on some releases — if you want that on the image tags too, we can add it. Your call. Does this address your concern? If the semver logic and the single-workflow approach look good, I can mark the architecture as complete.
hitanshu commented 2026-07-08 19:47:42 +00:00
Owner
Copy Link

@Archie, we can do away with the pa- prefix, this looks good, can you review thee final spec. then we can have @Dave implement it !

@Archie, we can do away with the `pa-` prefix, this looks good, can you review thee final spec. then we can have @Dave implement it !
Archie commented 2026-07-08 19:49:58 +00:00
Member
Copy Link

✅ Final Specification — Approved & Ready for Implementation

@hitanshu confirmed:

  • Option B (Single Workflow) ✅ — One workflow, branch-conditioned logic
  • Drop pa- prefix ✅ — Git tags and image tags use plain semver (e.g., 0.26.0, not pa-0.26.0)

Here is the final, implementation-ready workflow file incorporating all decisions:

Final Workflow: .gitea/workflows/portainer_automation_build_push.yml

name: Build & Push Portainer Automation
run-name: PA Build started by ${{ gitea.actor }}

on:
  push:
    branches:
      - test      # → PATCH bump, build & tag as test
      - main      # → MINOR bump, promote test→prod
  workflow_dispatch:
    inputs:
      environment:
        description: 'Target environment (test → PATCH bump, prod → MINOR bump)'
        required: true
        default: 'test'
        type: choice
        options:
          - test
          - prod

jobs:
  version:
    runs-on: ubuntu-latest
    outputs:
      new_version: ${{ steps.semver.outputs.new_version }}
      target_env: ${{ steps.env.outputs.target_env }}
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Determine environment
        id: env
        run: |
          if [[ "${{ github.event_name }}" == "workflow_dispatch" ]]; then
            ENV="${{ inputs.environment }}"
          else
            # Push events: test branch → test env, main branch → prod env
            [[ "${{ github.ref_name }}" == "main" ]] && ENV="prod" || ENV="${{ github.ref_name }}"
          fi
          # Validate
          if [[ "$ENV" != "test" && "$ENV" != "prod" ]]; then
            echo "❌ Invalid environment: $ENV. Must be 'test' or 'prod'."
            exit 1
          fi
          echo "target_env=$ENV" >> $GITHUB_OUTPUT          

      - name: Calculate semver bump
        id: semver
        run: |
          VERSION=$(git describe --tags --abbrev=0 2>/dev/null || echo "0.0.0")
          echo "Latest tag: ${VERSION}"
          MAJOR=$(echo ${VERSION} | cut -d "." -f 1)
          MINOR=$(echo ${VERSION} | cut -d "." -f 2)
          PATCH=$(echo ${VERSION} | cut -d "." -f 3)

          if [[ "${{ steps.env.outputs.target_env }}" == "prod" ]]; then
            # MINOR bump, reset PATCH
            NEW_MINOR=$((MINOR + 1))
            NEW_VERSION="${MAJOR}.${NEW_MINOR}.0"
            echo "Production → minor bump: ${NEW_VERSION}"
          else
            # test → PATCH bump
            NEW_PATCH=$((PATCH + 1))
            NEW_VERSION="${MAJOR}.${MINOR}.${NEW_PATCH}"
            echo "Test → patch bump: ${NEW_VERSION}"
          fi
          echo "new_version=${NEW_VERSION}" >> $GITHUB_OUTPUT          

  build-and-push:
    runs-on: ubuntu-latest
    needs: version
    container:
      image: 192.168.0.100:8928/hithomelabs/ci-runner:1.0.0
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Install JDK (Alpine package)
        run: |
          apk add --no-cache openjdk17-jdk
          echo "JAVA_HOME=/usr/lib/jvm/java-17-openjdk" >> "$GITHUB_ENV"          

      - name: Validate Gradle Wrapper (offline checksum)
        run: |
          sha256sum --check gradle/wrapper/gradle-wrapper.jar.sha256          

      - name: Create and push git tag
        run: |
          echo "New version: ${{ needs.version.outputs.new_version }}"
          git config --global user.name "${{ gitea.actor }}"
          git config --global user.email "${{ gitea.actor }}@users.noreply.github.com"
          git tag -a "${{ needs.version.outputs.new_version }}" \
            -m "Push PA version ${{ needs.version.outputs.new_version }}"
          git push origin "${{ needs.version.outputs.new_version }}"          

      - name: Log in to Gitea Docker Registry
        uses: docker/login-action@v3
        with:
          registry: 'http://192.168.0.100:8928'
          username: hitanshu
          password: ${{ secrets.TOKEN }}

      - name: Build image (test) or promote (prod)
        run: |
          ENV="${{ needs.version.outputs.target_env }}"
          VER="${{ needs.version.outputs.new_version }}"
          REG="192.168.0.100:8928/hithomelabs/portainer-automation"

          if [[ "$ENV" == "test" ]]; then
            echo "🔨 Building fresh image for test"
            ./gradlew :portainer-automation:bootBuildImage --imageName="${REG}:${VER}"
            docker tag "${REG}:${VER}" "${REG}:test"
            docker push "${REG}:test"
            docker push "${REG}:${VER}"
          else
            echo "♻️ Promoting test image to prod"
            docker pull "${REG}:test"
            docker tag "${REG}:test" "${REG}:${VER}"
            docker tag "${REG}:${VER}" "${REG}:prod"
            docker push "${REG}:prod"
            docker push "${REG}:${VER}"
          fi

Key Changes from Current Workflow

Aspect Current (test-only) Final (parameterized)
Trigger branches test only test + main + workflow_dispatch
Git tag prefix pa-0.x.x 0.x.x (no prefix)
Main branch behavior ❌ No workflow ♻️ Pulls test image, tags as prod
Manual trigger ❌ Not possible ✅ workflow_dispatch with env choice
Env validation ❌ None ✅ Fails early on invalid env

Trigger → Behavior Matrix

Trigger Env Semver Bump Action Image Tags Pushed
Push test test PATCH+1 Build fresh 0.x.y, test
Push main prod MINOR+1 Promote test→prod 0.x.0, prod
workflow_dispatch test test PATCH+1 Build fresh 0.x.y, test
workflow_dispatch prod prod MINOR+1 Promote test→prod 0.x.0, prod

Implementation Order for @Dave

  1. Replace .gitea/workflows/portainer_automation_build_push.yml with the final YAML above on the test branch
  2. Push to test → verify the workflow runs, builds, and tags correctly
  3. Test workflow_dispatch with env: test manually
  4. Merge test → main → verify the workflow runs with prod env (promotes test→prod)
  5. Test workflow_dispatch with env: prod manually
  6. ✅ Unblocks #140 for any remaining production-specific concerns

Dependency Update

  • Closes architecture phase for #139
  • #139 blocks #140 (already labeled)
  • #140 is now unblocked once this is implemented and merged

Architect Agent — final spec approved. Ready for @Dave to implement.

## ✅ Final Specification — Approved & Ready for Implementation @hitanshu confirmed: - **Option B (Single Workflow)** ✅ — One workflow, branch-conditioned logic - **Drop `pa-` prefix** ✅ — Git tags and image tags use plain semver (e.g., `0.26.0`, not `pa-0.26.0`) Here is the **final, implementation-ready workflow file** incorporating all decisions: --- ### Final Workflow: `.gitea/workflows/portainer_automation_build_push.yml` ```yaml name: Build & Push Portainer Automation run-name: PA Build started by ${{ gitea.actor }} on: push: branches: - test # → PATCH bump, build & tag as test - main # → MINOR bump, promote test→prod workflow_dispatch: inputs: environment: description: 'Target environment (test → PATCH bump, prod → MINOR bump)' required: true default: 'test' type: choice options: - test - prod jobs: version: runs-on: ubuntu-latest outputs: new_version: ${{ steps.semver.outputs.new_version }} target_env: ${{ steps.env.outputs.target_env }} steps: - uses: actions/checkout@v4 with: fetch-depth: 0 - name: Determine environment id: env run: | if [[ "${{ github.event_name }}" == "workflow_dispatch" ]]; then ENV="${{ inputs.environment }}" else # Push events: test branch → test env, main branch → prod env [[ "${{ github.ref_name }}" == "main" ]] && ENV="prod" || ENV="${{ github.ref_name }}" fi # Validate if [[ "$ENV" != "test" && "$ENV" != "prod" ]]; then echo "❌ Invalid environment: $ENV. Must be 'test' or 'prod'." exit 1 fi echo "target_env=$ENV" >> $GITHUB_OUTPUT - name: Calculate semver bump id: semver run: | VERSION=$(git describe --tags --abbrev=0 2>/dev/null || echo "0.0.0") echo "Latest tag: ${VERSION}" MAJOR=$(echo ${VERSION} | cut -d "." -f 1) MINOR=$(echo ${VERSION} | cut -d "." -f 2) PATCH=$(echo ${VERSION} | cut -d "." -f 3) if [[ "${{ steps.env.outputs.target_env }}" == "prod" ]]; then # MINOR bump, reset PATCH NEW_MINOR=$((MINOR + 1)) NEW_VERSION="${MAJOR}.${NEW_MINOR}.0" echo "Production → minor bump: ${NEW_VERSION}" else # test → PATCH bump NEW_PATCH=$((PATCH + 1)) NEW_VERSION="${MAJOR}.${MINOR}.${NEW_PATCH}" echo "Test → patch bump: ${NEW_VERSION}" fi echo "new_version=${NEW_VERSION}" >> $GITHUB_OUTPUT build-and-push: runs-on: ubuntu-latest needs: version container: image: 192.168.0.100:8928/hithomelabs/ci-runner:1.0.0 steps: - uses: actions/checkout@v4 with: fetch-depth: 0 - name: Install JDK (Alpine package) run: | apk add --no-cache openjdk17-jdk echo "JAVA_HOME=/usr/lib/jvm/java-17-openjdk" >> "$GITHUB_ENV" - name: Validate Gradle Wrapper (offline checksum) run: | sha256sum --check gradle/wrapper/gradle-wrapper.jar.sha256 - name: Create and push git tag run: | echo "New version: ${{ needs.version.outputs.new_version }}" git config --global user.name "${{ gitea.actor }}" git config --global user.email "${{ gitea.actor }}@users.noreply.github.com" git tag -a "${{ needs.version.outputs.new_version }}" \ -m "Push PA version ${{ needs.version.outputs.new_version }}" git push origin "${{ needs.version.outputs.new_version }}" - name: Log in to Gitea Docker Registry uses: docker/login-action@v3 with: registry: 'http://192.168.0.100:8928' username: hitanshu password: ${{ secrets.TOKEN }} - name: Build image (test) or promote (prod) run: | ENV="${{ needs.version.outputs.target_env }}" VER="${{ needs.version.outputs.new_version }}" REG="192.168.0.100:8928/hithomelabs/portainer-automation" if [[ "$ENV" == "test" ]]; then echo "🔨 Building fresh image for test" ./gradlew :portainer-automation:bootBuildImage --imageName="${REG}:${VER}" docker tag "${REG}:${VER}" "${REG}:test" docker push "${REG}:test" docker push "${REG}:${VER}" else echo "♻️ Promoting test image to prod" docker pull "${REG}:test" docker tag "${REG}:test" "${REG}:${VER}" docker tag "${REG}:${VER}" "${REG}:prod" docker push "${REG}:prod" docker push "${REG}:${VER}" fi ``` --- ### Key Changes from Current Workflow | Aspect | Current (test-only) | Final (parameterized) | |--------|-------------------|----------------------| | **Trigger branches** | `test` only | `test` + `main` + `workflow_dispatch` | | **Git tag prefix** | `pa-0.x.x` | `0.x.x` (no prefix) | | **Main branch behavior** | ❌ No workflow | ♻️ Pulls test image, tags as prod | | **Manual trigger** | ❌ Not possible | ✅ `workflow_dispatch` with env choice | | **Env validation** | ❌ None | ✅ Fails early on invalid env | ### Trigger → Behavior Matrix | Trigger | Env | Semver Bump | Action | Image Tags Pushed | |---------|-----|-------------|--------|-------------------| | Push `test` | test | PATCH+1 | Build fresh | `0.x.y`, `test` | | Push `main` | prod | MINOR+1 | Promote test→prod | `0.x.0`, `prod` | | `workflow_dispatch` test | test | PATCH+1 | Build fresh | `0.x.y`, `test` | | `workflow_dispatch` prod | prod | MINOR+1 | Promote test→prod | `0.x.0`, `prod` | --- ### Implementation Order for @Dave 1. **Replace** `.gitea/workflows/portainer_automation_build_push.yml` with the final YAML above on the `test` branch 2. **Push to `test`** → verify the workflow runs, builds, and tags correctly 3. **Test `workflow_dispatch`** with `env: test` manually 4. **Merge `test` → `main`** → verify the workflow runs with `prod` env (promotes test→prod) 5. **Test `workflow_dispatch`** with `env: prod` manually 6. ✅ Unblocks **#140** for any remaining production-specific concerns --- ### Dependency Update - Closes architecture phase for #139 - #139 blocks #140 (already labeled) - #140 is now unblocked once this is implemented and merged --- _Architect Agent — final spec approved. Ready for @Dave to implement._
Archie added the
architect:complete
 label 2026-07-08 19:50:01 +00:00
Dave commented 2026-07-08 19:53:35 +00:00
Member
Copy Link

Implementation Complete ✅

PR #141 has been created implementing the final architecture spec (Option B — Single Parameterized Workflow).

PR: #141
Branch: ISSUE-139 (from Dave/CFTunnels)
Target: Hithomelabs/CFTunnels:test

Changes Applied

  • Replaced .gitea/workflows/portainer_automation_build_push.yml with the final YAML from Archie's spec
  • Added push triggers for both test and main branches
  • Added workflow_dispatch with environment input (choice: test/prod)
  • Environment determination with validation (fails early on invalid env)
  • Semver calculation: PATCH bump on test, MINOR bump on main/prod
  • Removed pa- prefix from git tags (plain semver now)
  • Test builds fresh image; main/prod promotes existing test image

@hitanshu @Archie — ready for review.

## Implementation Complete ✅ PR #141 has been created implementing the final architecture spec (Option B — Single Parameterized Workflow). **PR**: https://gitea.hithomelabs.com/Hithomelabs/CFTunnels/pulls/141 **Branch**: `ISSUE-139` (from `Dave/CFTunnels`) **Target**: `Hithomelabs/CFTunnels:test` ### Changes Applied - Replaced `.gitea/workflows/portainer_automation_build_push.yml` with the final YAML from Archie's spec - Added `push` triggers for both `test` and `main` branches - Added `workflow_dispatch` with `environment` input (choice: test/prod) - Environment determination with validation (fails early on invalid env) - Semver calculation: PATCH bump on test, MINOR bump on main/prod - Removed `pa-` prefix from git tags (plain semver now) - Test builds fresh image; main/prod promotes existing test image @hitanshu @Archie — ready for review.
Linus commented 2026-07-08 20:00:55 +00:00
Member
Copy Link

Lead Agent Review — PR #141

PR #141 ([ISSUE-139] Parameterize portainer-automation build workflow for multi-environment reuse) has been reviewed.

Review Result: APPROVED ✅

The PR correctly implements the parameterization of the portainer_automation_build_push.yml workflow with:

  • Test branch → PATCH bump, build fresh
  • Main branch → MINOR bump, promote test→prod
  • workflow_dispatch support for manual env selection
  • Early validation of environment parameter

Key Recommendations (documented in PR review):

  1. Tag prefix change — The pa- prefix was removed from git tags. Confirm with architect/PM.
  2. Docker-in-Docker — Ensure CI runner has Docker socket mounted for docker commands.
  3. Prod image pull — Use digest pinning for prod promotion to avoid stale cache issues.
  4. Tag collision — Clean up old pa-* tags to avoid version confusion.
  5. workflow_dispatch ref — Document that dispatch from main builds from main code.

Effort: S (2-5 days)

Complexity: Medium

## Lead Agent Review — PR #141 **PR #141** (`[ISSUE-139] Parameterize portainer-automation build workflow for multi-environment reuse`) has been reviewed. ### Review Result: **APPROVED** ✅ The PR correctly implements the parameterization of the `portainer_automation_build_push.yml` workflow with: - Test branch → PATCH bump, build fresh - Main branch → MINOR bump, promote test→prod - `workflow_dispatch` support for manual env selection - Early validation of environment parameter ### Key Recommendations (documented in PR review): 1. **Tag prefix change** — The `pa-` prefix was removed from git tags. Confirm with architect/PM. 2. **Docker-in-Docker** — Ensure CI runner has Docker socket mounted for `docker` commands. 3. **Prod image pull** — Use digest pinning for prod promotion to avoid stale cache issues. 4. **Tag collision** — Clean up old `pa-*` tags to avoid version confusion. 5. **workflow_dispatch ref** — Document that dispatch from `main` builds from main code. ### Effort: S (2-5 days) ### Complexity: Medium
Linus added the
complexity:medium
effort:s
lead:complete
 labels 2026-07-08 20:01:13 +00:00
Dave commented 2026-07-09 05:02:44 +00:00
Member
Copy Link

Investigation: portainer_automation_build_push not registering on test

Root Cause

The workflow_dispatch input used type: choice with options: [test, prod]. The Gitea Actions runner in this instance may not fully support the choice type with the options subfield, causing the entire workflow to silently fail registration when the runner reloads the workflow definitions.

Evidence:

  • The workflow file exists on test, is valid YAML, and has correct syntax
  • integration_test.yaml uses bare workflow_dispatch: (no inputs) — proven working
  • This was the only workflow using type: choice + options in its workflow_dispatch inputs
  • No other workflow had registration issues

Fix (PR #147)

Changed the environment input from:

type: choice
options:
  - test
  - prod

to:

type: string

The workflow already has runtime validation (lines 40-44) that rejects invalid environment values with a clear error, so the UI-level choice constraint was redundant.

PR: #147

## Investigation: `portainer_automation_build_push` not registering on `test` ### Root Cause The `workflow_dispatch` input used `type: choice` with `options: [test, prod]`. The Gitea Actions runner in this instance may not fully support the `choice` type with the `options` subfield, causing the entire workflow to **silently fail registration** when the runner reloads the workflow definitions. **Evidence:** - The workflow file exists on `test`, is valid YAML, and has correct syntax - `integration_test.yaml` uses bare `workflow_dispatch:` (no inputs) — proven working - This was the **only** workflow using `type: choice` + `options` in its `workflow_dispatch` inputs - No other workflow had registration issues ### Fix (PR #147) Changed the `environment` input from: ```yaml type: choice options: - test - prod ``` to: ```yaml type: string ``` The workflow already has runtime validation (lines 40-44) that rejects invalid environment values with a clear error, so the UI-level `choice` constraint was redundant. **PR:** https://gitea.hithomelabs.com/Hithomelabs/CFTunnels/pulls/147
Dave commented 2026-07-09 05:05:00 +00:00
Member
Copy Link

Added a related fix to PR #147: Removed the portainer-automation service block from docker-compose.yaml on the ISSUE-139-fix-workflow-registration branch.

Context: Stack 17 (cftunnels_gitea_vcs_test on dev Portainer) deploys from this compose file but still had a portainer-automation service defined — even though that service was already split into its own independent stack (stack 57, portainer_svc_vcs_test) using portainer-automation/docker-compose.yaml. Both stacks tried to bind port 8081, causing a conflict that left the CFTunnels stack containers stuck in "Created" state.

The fix removes the duplicate service definition so it no longer conflicts with the standalone portainer-automation stack.

Added a related fix to PR #147: Removed the `portainer-automation` service block from `docker-compose.yaml` on the `ISSUE-139-fix-workflow-registration` branch. **Context:** Stack 17 (`cftunnels_gitea_vcs_test` on dev Portainer) deploys from this compose file but still had a `portainer-automation` service defined — even though that service was already split into its own independent stack (stack 57, `portainer_svc_vcs_test`) using `portainer-automation/docker-compose.yaml`. Both stacks tried to bind port 8081, causing a conflict that left the CFTunnels stack containers stuck in "Created" state. The fix removes the duplicate service definition so it no longer conflicts with the standalone portainer-automation stack.
Dave commented 2026-07-09 05:44:40 +00:00
Member
Copy Link

Dev Implementation Complete

PR created: #149

Changes

  1. Removed inputs block from workflow_dispatch (Gitea 1.22.x doesn't support it)
  2. Simplified "Determine environment" step to purely branch-based logic

How it works

  • Push to test → PATCH bump, build & tag as test
  • Push to main → MINOR bump, promote test→prod
  • Manual workflow_dispatch → same branch-based logic (no custom inputs)
  • The "Run workflow" button will now appear in Gitea Actions UI

Commit

c9dea2a91d757a6f0a17db6c0e91849c7928582d

## Dev Implementation Complete PR created: https://gitea.hithomelabs.com/Hithomelabs/CFTunnels/pulls/149 ### Changes 1. Removed `inputs` block from `workflow_dispatch` (Gitea 1.22.x doesn't support it) 2. Simplified "Determine environment" step to purely branch-based logic ### How it works - Push to `test` → PATCH bump, build & tag as test - Push to `main` → MINOR bump, promote test→prod - Manual `workflow_dispatch` → same branch-based logic (no custom inputs) - The "Run workflow" button will now appear in Gitea Actions UI ### Commit `c9dea2a91d757a6f0a17db6c0e91849c7928582d`
Dave commented 2026-07-09 06:12:08 +00:00
Member
Copy Link

Merge conflicts on PR #149 have been resolved.

What was done:

  1. Merged latest test branch into ISSUE-139-remove-inputs
  2. Resolved the conflict in .gitea/workflows/portainer_automation_build_push.yml — the test branch had changed the inputs block (type: choice → type: string), while the PR branch removed it entirely. Resolution: kept the PR's version (no inputs block, simplified branch-based environment step).
  3. Also picked up the docker-compose.yaml change from test (removing portainer-automation service).

Current state:

  • PR #149 now shows ✅ mergeable — ready for review and merge.
Merge conflicts on PR #149 have been resolved. **What was done:** 1. Merged latest `test` branch into `ISSUE-139-remove-inputs` 2. Resolved the conflict in `.gitea/workflows/portainer_automation_build_push.yml` — the `test` branch had changed the `inputs` block (`type: choice` → `type: string`), while the PR branch removed it entirely. Resolution: kept the PR's version (no inputs block, simplified branch-based environment step). 3. Also picked up the `docker-compose.yaml` change from `test` (removing portainer-automation service). **Current state:** - PR #149 now shows ✅ **mergeable** — ready for review and merge.
Polly closed this issue 2026-07-09 17:24:11 +00:00
Polly commented 2026-07-09 17:24:28 +00:00
Author
Member
Copy Link

Closed ✅ — Implementation completed via CFTunnels PRs:

  • #141 — Parameterize portainer-automation build workflow (merged to test)
  • #147 — Fix workflow registration on test (merged to test)
  • #149 — Remove workflow_dispatch inputs for Gitea 1.22.x compat (merged to test)

All carried to main via PR #152.

**Closed ✅** — Implementation completed via CFTunnels PRs: - [#141](https://gitea.hithomelabs.com/Hithomelabs/CFTunnels/pulls/141) — Parameterize portainer-automation build workflow (merged to test) - [#147](https://gitea.hithomelabs.com/Hithomelabs/CFTunnels/pulls/147) — Fix workflow registration on test (merged to test) - [#149](https://gitea.hithomelabs.com/Hithomelabs/CFTunnels/pulls/149) — Remove workflow_dispatch inputs for Gitea 1.22.x compat (merged to test) All carried to `main` via PR #152.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
architect:complete

Architecture analysis completed

  
blocked-by:#139

Blocked by issue #139

  
blocks:#140

Blocks issue #140

  
bug

Defect or regression

  
CI/CD

CI/CD pipeline improvements

  
complexity:low

Low complexity - straightforward implementation

  
complexity:medium

Medium complexity - some unknowns

  
complexity:medium

Medium complexity - some nuance and risk areas

  
config

Configuration files and settings

  
depends-on:#124

Depends on architecture decision issue #124

  
docker

Docker-related tasks

  
docs

Documentation updates and improvements

  
effort:l

L effort estimate - 2-4 weeks (large feature, complex)

  
effort:s

S effort estimate - 2-5 days (small feature, well-defined)

  
effort:xs

XS effort estimate - 1-2 days

  
epic/development

Epic for development phase work

  
lead:complete

Lead engineer review completed

  
needs-decision

Requires human decision before proceeding

  
performance

Performance improvements

  
priority:critical

Must do immediately

  
priority:high

Important for current milestone

  
priority:low

Nice to have

  
priority:medium

Valuable but not urgent

  
security

Security-related concerns

  
spike

Research / exploration

  
story-points:1

Trivial effort

  
story-points:3

Small effort

  
story-points:5

Medium effort

  
story-points:8

Large effort

  
tech-debt

Refactoring / improvement

  
test

Testing-related tasks

  
user-story

Standard user story

  
architect:complete

Architect phase completed

  
complexity:high

High complexity

  
complexity:low

Low complexity

  
complexity:medium

Medium complexity

  
cross-repo

Cross-repository item

  
cross-repo-dev

Cross-repository development

  
dev:in-progress

Development in progress

  
effort:l

Large effort (2-4 weeks)

  
effort:m

Medium effort (1-2 weeks)

  
effort:s

Small effort (2-5 days)

  
effort:xl

Extra large effort (4+ weeks)

  
effort:xs

Extra small effort (1-2 days)

  
epic
analytics
Data analytics of platform data and logs analysis.

  
epic
development
Developing new features, services. front and and back end as well as batch jobs

  
epic
devops
Epic related to CI/CD pipeline, runners, setup and workflow triggers

  
epic
infra
Epic related to infrastructure tasks, configuring hard drives, network equipment, firewalls, anything involving getting hands dirty.

  
epic
observability
Observability stack, uptime, service discovery, network, firewall, processes, resource consumption etc.

  
epic
platform
Related to authentication, authorization, keys, passwords, configs. Updates and upgrades related to platform.

  
epic
product
Issues discussing products and features come over here.

  
lead:complete

Lead/Code review phase completed

  
needs-decision

Requires user decision/selection

  
pipeline-complete

Pipeline completed successfully

  
pipeline-error

Pipeline failed with error

  
pipeline-running

Pipeline is currently running

  
priority
later
To be done but can wait. Generally areas that don't want immediate attention and warrant pre-planning, analysis and/or design

  
priority
next
Not a burning issue but needs to be worked on next. Generally should not be blocked by any issue other than priority::now

  
priority
now
Immediate priority, critical for PROD go-live

  
start-pipeline

Trigger the SDLC pipeline to start

  
status
acceptance
Testing results are good and issue looks good to deploy. It is a pre-deployment sign-off of test results

  
status
blocked
Need to solve another issue before this issue can be picked. The issue is blocked till the blocking issue isn't resolved

  
status
done
Issue deployment successful.

  
status
in progress
Issue has been picked up and someone is working on it.

  
status
in review
The issue has been work on but, a review has been requested, generally good to transition to this if all PRs raised require review or are reviewed.

  
status
in testing
Code review complete and issue is in testing in lower environment. P.S. This means unit tests have already been written.

  
status
ready
Issue does not have any blocker and is ready to be picked.

  
status
refine
Something working already well in PROD but a change that makes life a little more easier, like skip into in netflix. Issues that signify added convenience.

  
status
triage
Issue is requested but not scoped. Need to be added to systematically review and categorize

  
subtask

Subtask issue

  
type
analysis
An issue to perform analysis, exploring deign and implementation decisions/ considerations.

  
type
bug
A bug, needs to be fixed, raised out of an incident.

  
type
hygiene
Features remain the same, makes the platform, faster, better and less-error prone. Makes developer/ system-admin life easier

  
type
mantainence
Primarily version upgrades

  
type
story
Something new, a new feature !

  
user-story

PM-created user story

No Label
architect:complete
blocked-by:#139
blocks:#140
bug
CI/CD
complexity:low
complexity:medium
complexity:medium
config
depends-on:#124
docker
docs
effort:l
effort:s
effort:xs
epic/development
lead:complete
needs-decision
performance
priority:critical
priority:high
priority:low
priority:medium
security
spike
story-points:1
story-points:3
story-points:5
story-points:8
tech-debt
test
user-story
architect:complete
complexity:high
complexity:low
complexity:medium
cross-repo
cross-repo-dev
dev:in-progress
effort:l
effort:m
effort:s
effort:xl
effort:xs
epic
analytics
epic
development
epic
devops
epic
infra
epic
observability
epic
platform
epic
product
lead:complete
needs-decision
pipeline-complete
pipeline-error
pipeline-running
priority
later
priority
next
priority
now
start-pipeline
status
acceptance
status
blocked
status
done
status
in progress
status
in review
status
in testing
status
ready
status
refine
status
triage
subtask
type
analysis
type
bug
type
hygiene
type
mantainence
type
story
user-story
Milestone
Clear milestone
No items
No Milestone
Portainer Automation — Production & Parameterization
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
5 Participants
Notifications
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: Hithomelabs/CFTunnels#139
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?