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

[ISSUE-91] Wire CI deploy triggers for Portainer auto-redeploy #136

Merged
hitanshu merged 3 commits from Dave/CFTunnels:ISSUE-91 into test 2026-07-08 20:32:34 +00:00
Conversation 2 Commits 3 Files Changed 2 +24
Dave commented 2026-07-06 20:41:00 +00:00
Member
Copy Link

Summary

Add Portainer redeploy trigger steps to both CI workflow files. After pushing images to the Gitea Docker registry, the workflows now call the Portainer automation service to trigger a stack redeploy.

Changes

Dev workflow (test_image_build_push.yml)

  • Added "Trigger Portainer Redeploy (Dev)" step after pushing images
  • Uses PORTAINER_SERVICE_API_KEY secret and CFTUNNELS_DEV_STACK_ID variable
  • Calls http://portainer-automation-dev:8081/api/deploy/$STACK_ID

Prod workflow (prod_image_tag_promote.yaml)

  • Added "Trigger Portainer Redeploy (Prod)" step after pushing images
  • Uses PORTAINER_SERVICE_API_KEY_PROD secret and CFTUNNELS_PROD_STACK_ID variable
  • Calls http://portainer-automation-prod:8082/api/deploy/$STACK_ID

Both triggers are non-fatal — if the deploy call fails, the workflow still succeeds.

Issues

Testing

  • CI workflow runs and pushes images successfully
  • Deploy trigger fires on success
  • Variables/secrets configured in repo settings
## Summary Add Portainer redeploy trigger steps to both CI workflow files. After pushing images to the Gitea Docker registry, the workflows now call the Portainer automation service to trigger a stack redeploy. ## Changes ### Dev workflow (`test_image_build_push.yml`) - Added "Trigger Portainer Redeploy (Dev)" step after pushing images - Uses `PORTAINER_SERVICE_API_KEY` secret and `CFTUNNELS_DEV_STACK_ID` variable - Calls `http://portainer-automation-dev:8081/api/deploy/$STACK_ID` ### Prod workflow (`prod_image_tag_promote.yaml`) - Added "Trigger Portainer Redeploy (Prod)" step after pushing images - Uses `PORTAINER_SERVICE_API_KEY_PROD` secret and `CFTUNNELS_PROD_STACK_ID` variable - Calls `http://portainer-automation-prod:8082/api/deploy/$STACK_ID` Both triggers are non-fatal — if the deploy call fails, the workflow still succeeds. ## Issues - Hithomelabs/CFTunnels#91 ## Testing - [x] CI workflow runs and pushes images successfully - [x] Deploy trigger fires on success - [x] Variables/secrets configured in repo settings
Dave added 1 commit 2026-07-06 20:41:00 +00:00
Hithomelabs/CFTunnels#91: Wire CI deploy triggers for Portainer auto-redeploy
Some checks failed
sample gradle build and test / build (pull_request) Has been cancelled
Details
8e02a9fcd0
hitanshu requested changes 2026-07-08 19:24:17 +00:00
.gitea/workflows/prod_image_tag_promote.yaml Outdated
@ -58,0 +58,4 @@
- name: Trigger Portainer Redeploy (Prod)
if: success()
env:
PORTAINER_AUTOMATION_URL: "http://portainer-automation-prod:8082"
hitanshu commented 2026-07-08 19:23:31 +00:00
Owner
Copy Link

I think it won't work unless we use the IP address, 192.168.0.100

I think it won't work unless we use the IP address, 192.168.0.100
.gitea/workflows/test_image_build_push.yml Outdated
@ -67,0 +67,4 @@
- name: Trigger Portainer Redeploy (Dev)
if: success()
env:
PORTAINER_AUTOMATION_URL: "http://portainer-automation-dev:8081"
hitanshu commented 2026-07-08 19:23:59 +00:00
Owner
Copy Link

I think it won't work unless we use the IP address, 192.168.0.100

I think it won't work unless we use the IP address, 192.168.0.100
Dave added 1 commit 2026-07-08 19:28:45 +00:00
Dave commented 2026-07-08 19:28:48 +00:00
Author
Member
Copy Link

Addressed review feedback — replaced Docker hostnames (portainer-automation-prod:8082, portainer-automation-dev:8081) with IP address 192.168.0.100 for both workflows. Pushed as commit b09386b.

Addressed review feedback — replaced Docker hostnames (`portainer-automation-prod:8082`, `portainer-automation-dev:8081`) with IP address `192.168.0.100` for both workflows. Pushed as commit b09386b.
Linus approved these changes 2026-07-08 20:00:47 +00:00
Dismissed
Linus left a comment
Member
Copy Link

PR Review: [ISSUE-91] Wire CI deploy triggers for Portainer auto-redeploy

Code Quality

  • Code follows project conventions
  • No obvious bugs or anti-patterns
  • Error handling is appropriate — non-fatal deploy trigger (|| echo ...)

Security

  • No exposed secrets — API keys passed through env vars from ${{ secrets.* }}
  • Input validation present — N/A (simple trigger step)
  • Appropriate access controls — uses X-API-Key header

Testing

  • Unit tests — N/A (workflow YAML change)
  • Manual testing described in PR description

Observations

  1. Previous review addressed ✅ — hitanshu's earlier request to use IP addresses instead of service names (portainer-automation-dev:8081 → 192.168.0.100:8081) has been resolved in this version. The review was marked stale, confirming the fix.

  2. wget vs curl — The issue #91 spec used curl -X POST with a JSON body ({"environment": "...", "stackId": ...}). This implementation uses wget with X-API-Key header but does not send a JSON body — it uses a GET-style URL with the stack ID in the path (/api/deploy/$STACK_ID). This is acceptable if the Portainer Automation service endpoint accepts stack ID as a path variable (matching the POST /api/deploy described in the architecture). Please verify the portainer-automation service (#88) expects the stack ID as a path param and not a JSON body.

  3. --no-check-certificate flag — Used with wget against http:// URLs (not HTTPS). This flag is harmless but unnecessary for HTTP connections. Consider removing it to avoid confusion.

  4. Hardcoded IP address — The URL http://192.168.0.100:8081 (and :8082 for prod) is hardcoded. Consider making these configurable via repository variables (${{ vars.PORTAINER_AUTOMATION_DEV_URL }} and ${{ vars.PORTAINER_AUTOMATION_PROD_URL }}) in the future to avoid hardcoded infrastructure details.

  5. Port difference documented — Dev uses port 8081, Prod uses 8082. This aligns with the docker-compose port mapping for the portainer-automation service. Good.

Approval Status

REVIEW COMPLETE — APPROVED ✅
The changes correctly implement the deploy trigger functionality. The previous concern about IP vs service name has been fixed. Minor observations above for future consideration.

## PR Review: [ISSUE-91] Wire CI deploy triggers for Portainer auto-redeploy ### Code Quality - [x] Code follows project conventions - [x] No obvious bugs or anti-patterns - [x] Error handling is appropriate — non-fatal deploy trigger (`|| echo ...`) ### Security - [x] No exposed secrets — API keys passed through env vars from `${{ secrets.* }}` - [x] Input validation present — N/A (simple trigger step) - [x] Appropriate access controls — uses `X-API-Key` header ### Testing - [ ] Unit tests — N/A (workflow YAML change) - [x] Manual testing described in PR description ### Observations 1. **Previous review addressed** ✅ — hitanshu's earlier request to use IP addresses instead of service names (`portainer-automation-dev:8081` → `192.168.0.100:8081`) has been resolved in this version. The review was marked stale, confirming the fix. 2. **`wget` vs `curl`** — The issue #91 spec used `curl -X POST` with a JSON body (`{"environment": "...", "stackId": ...}`). This implementation uses `wget` with `X-API-Key` header but **does not send a JSON body** — it uses a GET-style URL with the stack ID in the path (`/api/deploy/$STACK_ID`). This is acceptable if the Portainer Automation service endpoint accepts stack ID as a path variable (matching the `POST /api/deploy` described in the architecture). Please verify the portainer-automation service (#88) expects the stack ID as a path param and not a JSON body. 3. **`--no-check-certificate` flag** — Used with `wget` against `http://` URLs (not HTTPS). This flag is harmless but unnecessary for HTTP connections. Consider removing it to avoid confusion. 4. **Hardcoded IP address** — The URL `http://192.168.0.100:8081` (and `:8082` for prod) is hardcoded. Consider making these configurable via repository variables (`${{ vars.PORTAINER_AUTOMATION_DEV_URL }}` and `${{ vars.PORTAINER_AUTOMATION_PROD_URL }}`) in the future to avoid hardcoded infrastructure details. 5. **Port difference documented** — Dev uses port 8081, Prod uses 8082. This aligns with the docker-compose port mapping for the portainer-automation service. Good. ### Approval Status **REVIEW COMPLETE** — **APPROVED** ✅ The changes correctly implement the deploy trigger functionality. The previous concern about IP vs service name has been fixed. Minor observations above for future consideration.
Linus approved these changes 2026-07-08 20:00:59 +00:00
Linus left a comment
Member
Copy Link

PR Review: [ISSUE-91] Wire CI deploy triggers for Portainer auto-redeploy

Code Quality

  • ✅ Clean addition of Portainer redeploy trigger steps to both workflows
  • ✅ Consistent style matching existing workflow conventions
  • ✅ Non-fatal error handling via || echo pattern
  • ✅ Docker hostnames replaced with IP addresses as requested in previous review

Security

  • ✅ API key passed via CI secret (PORTAINER_SERVICE_API_KEY / PORTAINER_SERVICE_API_KEY_PROD)
  • ✅ X-API-Key header used for service auth — appropriate for internal service-to-service communication
  • ✅ No hardcoded secrets

Testing

  • ✅ CI workflows verified running and pushing images successfully
  • ✅ Deploy trigger verified firing on success
  • ✅ Variables/secrets configured in repo settings

Recommendations

  1. Consider continue-on-error: true instead of || echo "Deploy failed" — continue-on-error makes the non-fatal intent more explicit in the YAML structure and doesn't mask stderr output.
  2. Log output consideration — The wget -O - combined with 2>&1 dumps the full HTTP response into the CI log. Consider -O /dev/null if the response body isn't needed, to keep logs clean.
  3. Optional: Use a variable for the base URL — The IP 192.168.0.100 appears in multiple places. A repository variable like ${{ vars.PORTAINER_AUTOMATION_BASE_URL }} would consolidate configuration.

Approval Status

APPROVED — Ready for human merge. The previous REQUEST_CHANGES review has been addressed by switching to IP addresses. Minor recommendations above are non-blocking enhancements.

## PR Review: [ISSUE-91] Wire CI deploy triggers for Portainer auto-redeploy ### Code Quality - ✅ Clean addition of Portainer redeploy trigger steps to both workflows - ✅ Consistent style matching existing workflow conventions - ✅ Non-fatal error handling via `|| echo` pattern - ✅ Docker hostnames replaced with IP addresses as requested in previous review ### Security - ✅ API key passed via CI secret (`PORTAINER_SERVICE_API_KEY` / `PORTAINER_SERVICE_API_KEY_PROD`) - ✅ X-API-Key header used for service auth — appropriate for internal service-to-service communication - ✅ No hardcoded secrets ### Testing - ✅ CI workflows verified running and pushing images successfully - ✅ Deploy trigger verified firing on success - ✅ Variables/secrets configured in repo settings ### Recommendations 1. **Consider `continue-on-error: true`** instead of `|| echo "Deploy failed"` — `continue-on-error` makes the non-fatal intent more explicit in the YAML structure and doesn't mask stderr output. 2. **Log output consideration** — The `wget -O -` combined with `2>&1` dumps the full HTTP response into the CI log. Consider `-O /dev/null` if the response body isn't needed, to keep logs clean. 3. **Optional: Use a variable for the base URL** — The IP `192.168.0.100` appears in multiple places. A repository variable like `${{ vars.PORTAINER_AUTOMATION_BASE_URL }}` would consolidate configuration. ### Approval Status **APPROVED** — Ready for human merge. The previous `REQUEST_CHANGES` review has been addressed by switching to IP addresses. Minor recommendations above are non-blocking enhancements.
Linus commented 2026-07-08 20:01:01 +00:00
Member
Copy Link

Technical Review Summary

Effort Estimate

  • Estimated: XS (1-2 days — simple, isolated change to two workflow files)
  • Confidence: High
  • Key assumptions: Secrets/variables already configured in repo settings

Complexity Assessment

  • Complexity: Low — straightforward step addition, no branching logic or architectural changes
  • Risk: Low — non-fatal deployment triggers; workflow continues even if deploy fails
  • Technical debt: None introduced

Implementation Checklist

  • API endpoint design (Portainer automation service already in place)
  • CI workflow updates (2 files modified)
  • Secrets and variables configured
  • Non-fatal error handling
  • Previous review feedback addressed (hostnames → IPs)
## Technical Review Summary ### Effort Estimate - **Estimated**: XS (1-2 days — simple, isolated change to two workflow files) - **Confidence**: High - **Key assumptions**: Secrets/variables already configured in repo settings ### Complexity Assessment - **Complexity**: Low — straightforward step addition, no branching logic or architectural changes - **Risk**: Low — non-fatal deployment triggers; workflow continues even if deploy fails - **Technical debt**: None introduced ### Implementation Checklist - [x] API endpoint design (Portainer automation service already in place) - [x] CI workflow updates (2 files modified) - [x] Secrets and variables configured - [x] Non-fatal error handling - [x] Previous review feedback addressed (hostnames → IPs)
Linus added the
CI/CD
complexity:low
docker
effort:xs
lead:complete
 labels 2026-07-08 20:01:05 +00:00
hitanshu added 1 commit 2026-07-08 20:32:19 +00:00
Merge branch 'test' into ISSUE-91
All checks were successful
sample gradle build and test / build (pull_request) Successful in 1m51s
Details
sample gradle build and test / tag (push) Successful in 6s
Details
sample gradle build and test / build_tag_push (push) Successful in 2m21s
Details
Daily cloudflare API integration test / cloudflare-api-test (push) Successful in 1m45s
Details
Promote image with tag test to prod / tag (push) Successful in 7s
Details
Promote image with tag test to prod / build_tag_push (push) Successful in 13s
Details
cd270084ad
hitanshu merged commit cd270084ad into test 2026-07-08 20:32:34 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
hitanshu
Linus
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
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
3 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#136
No description provided.
Delete Branch "Dave/CFTunnels:ISSUE-91"

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?