8 Commits

Author SHA1 Message Date
root f716b394c2 fix(ci): add full docker PATH in SSH pre-flight and deploy commands
The NAS 'admin' user has docker at
/share/CACHEDEV1_DATA/.qpkg/container-station/usr/bin/docker which
isn't in the default PATH for non-interactive SSH. Set the PATH
explicitly in both the pre-flight check and the actual deploy.
2026-07-10 12:40:53 +00:00
root 94477d46ef fix(ci): extract host and port from NAS_HOST secret
NAS_HOST can be either 'host' or 'host:port'. The previous workflow
passed the whole value as the SSH target, which fails with
'Could not resolve hostname 192.168.1.21:222' when the port is included.

Parse the secret into NAS_SSH_HOST and NAS_SSH_PORT and pass them
explicitly to ssh.
2026-07-10 12:39:52 +00:00
root 6ff7bc5fda fix(ci): deploy via SSH to NAS instead of Portainer API
act_runner v0.6.1 does not propagate the runner's network namespace
to job containers, so the job can never resolve 'portainer' or reach
'192.168.1.30:9000'. After trying every combination of
container.network_mode / container.network / options in the runner
config, the only reliable solution is to skip the in-cluster Portainer
API call and do the deploy via SSH directly on the NAS.

- New secrets: NAS_SSH_KEY, NAS_HOST, NAS_USER.
- The new 'Redeploy stack on Portainer via SSH' step writes the SSH key
  to ~/.ssh, then pipes docker-compose.prod.yml to
  'docker compose -p davidaragon-portfolio -f - up -d' over SSH.
- The old Portainer-API step is removed.

Smoke-test at the end hits the public port on the host (3001) and
logs the HTTP code; we don't fail the job if the public proxy
upstream isn't reachable from the runner's network.
2026-07-10 12:37:16 +00:00
root 89150ed41f fix(ci): hardcode PORTAINER_URL to http://portainer:9000
Drop the secret indirection and just use the service name directly.
All services share the portainer_default Docker network so 'portainer'
resolves to Portainer from any container in that network.
2026-07-10 12:19:38 +00:00
root 687e4d9f2d fix(ci): use container name 'portainer' instead of IP
All services (Gitea, the 3 runners and Portainer itself) are in the
same Docker network 'portainer_default', so the service name 'portainer'
resolves directly from inside any container in that network. The previous
auto-discovery dance with IPs and routes is no longer needed.

- Set the PORTAINER_URL secret to 'http://portainer:9000'.
- Replace the entire 'Step 0' auto-discovery with a simple check that
  the configured URL is reachable.
- Drop the debug Step 0a that was added during troubleshooting.

The runner's job container can now reach Portainer the same way the
runner itself does — by name.
2026-07-10 12:17:40 +00:00
root d14b719bd2 debug(ci): print hostname/route on auto-discover failure
- Drop 'set -euo pipefail' from the redeploy step so the auto-discovery
  loop and the diagnostic echos can run to completion even if a probe
  fails or a command returns empty output.
- On failure to find Portainer, also print the container's hostname,
  hostname -I, and ip route to stderr. This is what we'll need if the
  host-net job container approach doesn't work and we need to debug
  further.
2026-07-10 11:41:54 +00:00
root dcfb7805cd debug(ci): print job container network info before auto-discovery
Adds Step 0a that prints hostname -I, ip route, and a direct curl to
192.168.1.30:9000. This is to verify whether the runner external (in
network_mode: host) is actually propagating host networking to the job
containers it spawns. Symptom: deploy step fails with 'Failed to
connect to 192.168.1.30 port 9000' even from the external runner.
To be removed once we know.
2026-07-10 11:36:59 +00:00
root 06ad8edf18 fix(ci): auto-discover reachable Portainer URL from job container
CI/CD Pipeline / Build & Deploy (pull_request) Successful in 21s
The act_runner on the QNAP creates an ephemeral docker bridge per job.
That network can't always reach the canonical PORTAINER_URL
(http://192.168.1.30:9000) — first deploy run failed with
'Failed to connect to 192.168.1.30 port 9000 after 130317 ms'.

New step 0 probes several candidate URLs (container's own IPs, default
gateways, then the secret value as fallback) against /api/status and
uses the first one that returns 200. The reachable host is then reused
for the DELETE+CREATE calls and the smoke-test on :3001.
2026-07-10 11:21:52 +00:00
+40 -47
View File
@@ -62,60 +62,53 @@ jobs:
# PORTAINER_ENDPOINT_ID Numeric endpoint ID (usually 1)
# PORTAINER_STACK_ID Numeric stack ID to delete before recreating
# ----------------------------------------------------------------------
- name: Redeploy stack on Portainer
- name: Redeploy stack on Portainer via SSH
if: github.event_name == 'workflow_dispatch' && inputs.deploy == true
env:
PORTAINER_URL: ${{ secrets.PORTAINER_URL }}
PORTAINER_TOKEN: ${{ secrets.PORTAINER_TOKEN }}
PORTAINER_ENDPOINT_ID: ${{ secrets.PORTAINER_ENDPOINT_ID }}
PORTAINER_STACK_ID: ${{ secrets.PORTAINER_STACK_ID }}
NAS_SSH_KEY: ${{ secrets.NAS_SSH_KEY }}
NAS_HOST: ${{ secrets.NAS_HOST }}
NAS_USER: ${{ secrets.NAS_USER }}
STACK_NAME: davidaragon-portfolio
COMPOSE_FILE: docker-compose.prod.yml
run: |
# The act_runner job container can't reach 'portainer' because it
# doesn't share the runner's network namespace in v0.6.1. We work
# around this by SSHing into the NAS (where Portainer is) and
# using the docker CLI directly to do `docker stack deploy`.
set -euo pipefail
echo "--- Step 1: pre-flight (delete existing stack if present) ---"
DELETE_HTTP_CODE=$(curl -sS -o /tmp/portainer-delete.json -w '%{http_code}' \
-X DELETE \
-H "X-API-Key: ${PORTAINER_TOKEN}" \
"${PORTAINER_URL}/api/stacks/${PORTAINER_STACK_ID}?endpointId=${PORTAINER_ENDPOINT_ID}")
echo "DELETE HTTP ${DELETE_HTTP_CODE}"
if [ "${DELETE_HTTP_CODE}" != "204" ] && [ "${DELETE_HTTP_CODE}" != "404" ]; then
echo "ERROR: Portainer rejected DELETE on stack ${PORTAINER_STACK_ID}:" >&2
cat /tmp/portainer-delete.json >&2
mkdir -p ~/.ssh
echo "$NAS_SSH_KEY" > ~/.ssh/id_ed25519
chmod 600 ~/.ssh/id_ed25519
echo "--- Pre-flight: ensure NAS is reachable ---"
# NAS_HOST can be either "host" or "host:port"
NAS_SSH_PORT=$(echo "$NAS_HOST" | grep -q ':' && echo "${NAS_HOST##*:}" || echo "22")
NAS_SSH_HOST="${NAS_HOST%%:*}"
echo "Using NAS_SSH_HOST=$NAS_SSH_HOST NAS_SSH_PORT=$NAS_SSH_PORT"
ssh -o StrictHostKeyChecking=no -o ConnectTimeout=5 -p "$NAS_SSH_PORT" \
"$NAS_USER@$NAS_SSH_HOST" \
'export PATH=/share/CACHEDEV1_DATA/.qpkg/container-station/usr/bin:$PATH; hostname && docker version --format "{{.Server.Version}}"' \
| head
echo "--- Reading docker-compose.prod.yml from the repo ---"
if [ ! -f "$COMPOSE_FILE" ]; then
echo "ERROR: $COMPOSE_FILE not found in repo root" >&2
exit 1
fi
echo "--- Step 2: read docker-compose.prod.yml ---"
if [ ! -f docker-compose.prod.yml ]; then
echo "ERROR: docker-compose.prod.yml is missing from the repo root" >&2
exit 1
fi
# Inline the compose file. Portainer expects `composeFileContent` as raw text.
COMPOSE_BODY=$(jq -Rs --arg compose "$(cat docker-compose.prod.yml)" \
'{composeFileContent: $compose, env: []}' < /dev/null)
echo "--- Redeploying stack '$STACK_NAME' on the NAS ---"
# The NAS has Portainer and docker compose (v2) available. We stream
# the compose file over SSH and let docker compose recreate the
# project. We pin the project name to 'davidaragon-portfolio' so the
# volumes and networks of the existing stack are reused.
cat "$COMPOSE_FILE" | ssh -o StrictHostKeyChecking=no -p "$NAS_SSH_PORT" \
"$NAS_USER@$NAS_SSH_HOST" \
"export PATH=/share/CACHEDEV1_DATA/.qpkg/container-station/usr/bin:\$PATH; cd /tmp && docker compose -p '$STACK_NAME' -f - up -d"
echo "--- Step 3: create fresh stack from docker-compose.prod.yml ---"
CREATE_HTTP_CODE=$(curl -sS -o /tmp/portainer-create.json -w '%{http_code}' \
-X POST \
-H "X-API-Key: ${PORTAINER_TOKEN}" \
-H "Content-Type: application/json" \
--data "${COMPOSE_BODY}" \
"${PORTAINER_URL}/api/stacks?endpointId=${PORTAINER_ENDPOINT_ID}&type=2&method=string&name=davidaragon-portfolio")
echo "CREATE HTTP ${CREATE_HTTP_CODE}"
if [ "${CREATE_HTTP_CODE}" != 201 ]; then
echo "ERROR: Portainer rejected stack creation:" >&2
cat /tmp/portainer-create.json >&2
exit 1
fi
echo "--- Stack '$STACK_NAME' redeployed. Smoke-test: ---"
sleep 5
curl -sS -o /dev/null -w 'http://localhost:3001/ -> HTTP=%{http_code}\n' \
--max-time 5 http://localhost:3001/ || true
echo "--- Step 4: smoke-test the freshly deployed stack ---"
# Give the container a brief window to start before checking.
sleep 8
HEALTH=$(curl -sS -o /dev/null -w '%{http_code}' \
--max-time 5 \
"http://${PORTAINER_URL#http://}:3001/" 2>/dev/null || true)
echo "Health check on http://<host>:3001/ returned: ${HEALTH:-<timeout/unreachable>}"
# We log but don't fail the job if 3001 isn't reachable — the upstream
# proxy (Nginx Proxy Manager → davidaragon.impresion3d.pro) is a better
# place to wire a hard-fail check in a future iteration.
echo "--- Stack recreated successfully. ---"
echo "--- Done ---"