ci: gate redeploy step on workflow_dispatch.deploy=true #4

Merged
root merged 2 commits from feat/portainer-redeploy-step into main 2026-07-10 13:12:04 +02:00

2 Commits

Author SHA1 Message Date
root 70129b1e9f docs: add CI/CD optimization proposal (draft, post-first-deploy to refine)
CI/CD Pipeline / Build & Deploy (pull_request) Successful in 1m7s
Documents the current pipeline anatomy, the metrics to capture on the
first real run, hypothesised bottlenecks, and ranked optimisation
proposals. Placeholders for real numbers; to be filled in after the
first deploy lands.

Companion to the Portainer redeploy step in .gitea/workflows/ci-cd.yaml
on the same branch.
2026-07-10 11:11:34 +00:00
root ab6b4677b4 ci: gate redeploy step on workflow_dispatch.deploy=true
- Build pushes both :latest and :0.0.1 tags so the redeploy step uses the
  pinned version regardless of how the runner happened to be tagged before.
- Add a 4th step 'Redeploy stack on Portainer' that runs ONLY when the
  workflow is manually dispatched with deploy=true.
- Step does idempotent DELETE+CREATE on the existing stack via Portainer REST
  (PUT-edit would require more plumbing for a single-service stack).
- Smoke-tests http://<host>:3001/ after the stack recreates; logs the code
  but does not hard-fail the job (network-proxy reachable via NPM upstream).

Required new secrets (in addition to existing DOCKER_USERNAME/DOCKER_PASSWORD):
- PORTAINER_URL         e.g. http://192.168.1.30:9000
- PORTAINER_TOKEN       API access token from a Portainer user
- PORTAINER_ENDPOINT_ID numeric endpoint ID (usually 1)
- PORTAINER_STACK_ID    numeric stack ID to delete before recreating
2026-07-10 10:54:17 +00:00