# gates — re-run this repo's gate entry point on every push, on a machine that does not care who # pushed or what they typed. # # *** THIS REPORTS. IT CANNOT REFUSE. *** # # felhom repos push straight to `main` with no pull request, so there is no merge for a status # check to stand at. The refusing half is `.githooks/pre-push`, which is local to a clone and which # `git push --no-verify` skips; this half is what notices when that happened. Neither half is the # whole thing, and both are named in documentation/backlog/OPEN-ITEMS.md R-168. # # NO `uses:` STEP ANYWHERE, deliberately: JavaScript actions need a node runtime in the runner, and # the runner is a host-mode container with python3 and git and nothing else (see # homelab-manifests/gitea-system/act-runner.yaml for why it is not privileged). Probe P3 measured # that a plain `git fetch` of the pushed SHA from the in-cluster Gitea service is enough. # # A failing run must reach a person — a detector nobody hears is the defect R-29 filed, rebuilt one # layer up. That is the last step, and it runs ONLY on failure. name: gates on: [push] jobs: gates: runs-on: felhom-gates steps: - name: Fetch the pushed commit run: | # Shallow, and pinned to the exact SHA that was pushed — not to the branch tip, which can # move under us if two pushes race. Probe P3 proved the two are equal when done this way. git init -q . git remote add origin http://gitea.gitea-system.svc.cluster.local:3000/admin/felhom.eu.git git fetch -q --depth 1 origin "$GITHUB_SHA" git checkout -q FETCH_HEAD echo "checked out $(git rev-parse HEAD)" - name: Run the gate entry point # The ONLY thing CI runs. No go build, no go test, no linting, no deploy — those are either # already reliably run by a person or none of CI's business. The exit code IS the result: # no `|| true`, no pipe that could swallow it. run: python3 scripts/repo_gates.py --fast - name: Alarm on failure # THE POINT OF THE WHOLE THING. Probe P5 measured that a failed run produces NO mail, NO # notification row and NO log line from Gitea itself — a red tick in a web UI nobody watches # is exactly the shape R-29 filed against. So the run sends its own alarm, on the project's # existing transactional path (Resend, the same one the hub uses), and it prints the # provider's accepted id so "it was sent" is an observable rather than an assumption. if: failure() env: RESEND_API_KEY: ${{ secrets.RESEND_API_KEY }} run: | python3 - > payload.json <<'PY' import json, os repo = os.environ.get("GITHUB_REPOSITORY", "?") sha = os.environ.get("GITHUB_SHA", "?") run = os.environ.get("GITHUB_RUN_NUMBER", "?") srv = os.environ.get("GITHUB_SERVER_URL", "https://gitea.dooplex.hu") print(json.dumps({ "from": "Felhom CI ", "to": ["admin@felhom.eu"], "subject": "[felhom CI] gates FAILED in %s" % repo, "text": ( "The gate entry point exited non-zero.\n\n" "Repository : %s\n" "Commit : %s\n" "Run : %s/%s/actions/runs/%s\n\n" "The failing gate names itself in the run log.\n\n" "If the local pre-push hook was GREEN for this commit, then CI and the hook\n" "disagree - that is a finding about the gates themselves, not about CI, and it\n" "outranks whatever the push was for.\n" ) % (repo, sha, srv, repo, run), })) PY curl -sS --fail-with-body -X POST https://api.resend.com/emails \ -H "Authorization: Bearer $RESEND_API_KEY" \ -H "Content-Type: application/json" \ --data @payload.json > resend-response.json python3 -c "import json;print('RESEND-ACCEPTED id=%s' % json.load(open('resend-response.json'))['id'])"