diff --git a/.github/workflows/verify-fly-credential.yml b/.github/workflows/verify-fly-credential.yml new file mode 100644 index 0000000..edc9bfd --- /dev/null +++ b/.github/workflows/verify-fly-credential.yml @@ -0,0 +1,50 @@ +name: Verify Fly credential + +# Read-only proof that FLY_API_TOKEN authenticates against the wright-worker +# app. Deliberately separate from `Deploy Worker`. +# +# WHY THIS IS NOT A DISPATCHABLE DEPLOY +# ------------------------------------ +# `Deploy Worker` triggers only on a push touching apps/worker/**, so the +# obvious way to test a newly-added token is to re-run its last failed run. +# That run is commit e99cdbe from 2026-03-19, and wright-worker.fly.dev is +# currently serving a build someone deployed by hand from a local flyctl. +# Re-running it would push four-month-old code over a live service to test a +# credential. Adding workflow_dispatch to the deploy itself has the same +# hazard, one click further away. +# +# So this proves the credential and touches nothing. `flyctl auth whoami` and +# `flyctl status` read; they do not write. The real deploy stays push-gated and +# fires on the next genuine change to the worker. + +on: + workflow_dispatch: + +jobs: + verify: + runs-on: ubuntu-latest + environment: production + steps: + - name: Check the token is present + env: + FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }} + run: | + if [ -z "${FLY_API_TOKEN}" ]; then + echo "::error title=FLY_API_TOKEN missing::The secret is not visible to this job." + exit 1 + fi + echo "FLY_API_TOKEN is present (${#FLY_API_TOKEN} characters)." + + - uses: superfly/flyctl-actions/setup-flyctl@master + + - name: Authenticate and read app state (no writes) + env: + FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }} + run: | + set -euo pipefail + echo "--- whoami ---" + flyctl auth whoami + echo "--- status: wright-worker ---" + flyctl status --app wright-worker + echo + echo "The credential authenticates and can read the app. No deploy ran."