From 9fb918e54fb2d6143caa93625d636f2774cbea5b Mon Sep 17 00:00:00 2001 From: G <41178744+catomean@users.noreply.github.com> Date: Fri, 28 Aug 2026 08:09:39 +0200 Subject: [PATCH 1/2] fix(ci): point Actions at the bitbaum org, so merges and deploys resume MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The fleet moved to the bitbaum org. Actions' `uses:` resolver does not follow a repo transfer — unlike the REST API, `git clone` and `git push`, which all do. So every reference here still looked correct to every tool that could be used to check it, while the runs died before a single job started: zero jobs, no logs, and a bare "workflow file issue". That failure mode is invisible in the usual places. A PR shows CLEAN and MERGEABLE with no red check, because the workflow that would have reported the red never ran. Nothing is marked broken; work simply stops moving. Files changed: auto-merge.yml Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01UvjGNAS9CMfEGNW26tUR4P --- .github/workflows/auto-merge.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/workflows/auto-merge.yml b/.github/workflows/auto-merge.yml index f5b5bbc98..f4c6194b2 100644 --- a/.github/workflows/auto-merge.yml +++ b/.github/workflows/auto-merge.yml @@ -1,7 +1,7 @@ # Auto-merge — nobody is in the merge loop. # # Green, ready PRs merge themselves and deploy themselves. The policy lives in -# ONE place for the whole fleet — catomean/dotfiles, +# ONE place for the whole fleet — bitbaum/dotfiles, # scripts/ci/auto-merge-sweep.sh — and this file only says "run it, with these # settings". # @@ -42,7 +42,7 @@ permissions: jobs: sweep: - uses: catomean/dotfiles/.github/workflows/auto-merge-sweep.yml@master + uses: bitbaum/dotfiles/.github/workflows/auto-merge-sweep.yml@master with: base_branch: main ci_workflow: ci.yml From cfef7ffc3814a1e99eb16adc6fda3ef225703fa7 Mon Sep 17 00:00:00 2001 From: G <41178744+catomean@users.noreply.github.com> Date: Fri, 28 Aug 2026 08:24:07 +0200 Subject: [PATCH 2/2] fix(ci): restore secret scanning, which the org move silently disabled MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit gitleaks-action is free for PERSONAL accounts only. Under an organization it refuses to scan and exits "missing gitleaks license", so moving this repo into bitbaum turned secret scanning off while leaving the job, its name, and its place in the checks list exactly as they were. It failed loudly here only because the licence check errors. A wrapper that had skipped instead would have reported green while scanning nothing — and the comment above the step still read "Free for public repos; no license needed", so the file asserted the opposite of what was happening. Replaced with the gitleaks CLI, which is MIT and unaffected. Same scope as before: the incoming commit range, not full history (~173 pre-existing 2025-era findings live there and only a history rewrite clears them). Verified against 8.30.1 before writing it, because a secret scanner is exactly the kind of check that is trusted without ever being watched: - clean range -> exit 0 - planted sk-ant key -> exit 1, "leaks found" - EMPTY range -> exit 0, scans nothing, reports success That last one is why the step counts commits itself and fails on zero. A scanner that silently reads no commits is worse than one that is obviously broken, because it keeps reporting green. Note the first mutation attempt did NOT go red: it planted AWS's published EXAMPLEKEY, which gitleaks allowlists by design. The test was wrong, not the scanner. A mutation that stays green is a hole in the test. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01UvjGNAS9CMfEGNW26tUR4P --- .github/workflows/ci.yml | 60 +++++++++++++++++++++++++++++----------- 1 file changed, 44 insertions(+), 16 deletions(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index a2b4c5369..b9a9bbf5d 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -273,26 +273,54 @@ jobs: fetch-depth: 0 - name: Secret scan (gitleaks) - # Free for public repos; no license needed. Fails the job on any finding. + # The gitleaks CLI, not gitleaks-action. The action is free only for + # PERSONAL accounts; under an organization it refuses to scan at all and + # exits with "missing gitleaks license". Moving this repo into the + # bitbaum org therefore switched secret scanning off while leaving the + # job, its name, and its place in the checks list exactly as they were. + # It happened to fail loudly here — but only because the licence check + # errors; a wrapper that had instead skipped would have reported green + # while scanning nothing. The CLI itself is MIT and unaffected. # - # Skipped on workflow_dispatch, and only there. On push and pull_request - # the action scans the incoming commits; a dispatched run has no such - # range, so it falls back to scanning all ~2.6k commits of history and - # fails on ~173 pre-existing findings (2025-era .env commits) that only - # a history rewrite can clear — see the security audit, not CI's job. + # Scope is the incoming commit range, which is what the action scanned. + # Scanning all of history instead would fail on ~173 pre-existing + # findings (2025-era .env commits) that only a history rewrite can clear + # — see the security audit, not CI's job. Coverage is unchanged: every + # commit is still scanned in its PR run before it can merge. # - # This costs nothing in coverage: every commit still gets scanned in its - # PR run before it can merge. The alternative — baselining those 173 - # findings in .gitleaksignore — would mean allowlisting real historical - # credentials, which that file explicitly forbids. - # - # Auto-merge dispatches CI on main after each merge (a GITHUB_TOKEN push - # triggers nothing), so without this every automated merge left main red - # and CD, which chains off green CI, never deployed. + # Skipped on workflow_dispatch, and only there: a dispatched run has no + # incoming range. Auto-merge dispatches CI on main after each merge (a + # GITHUB_TOKEN push triggers nothing), so without that skip every + # automated merge would leave main red and CD would never deploy. if: github.event_name != 'workflow_dispatch' - uses: gitleaks/gitleaks-action@v3 env: - GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + GITLEAKS_VERSION: '8.30.1' + BASE_SHA: ${{ github.event.pull_request.base.sha || github.event.before }} + HEAD_SHA: ${{ github.event.pull_request.head.sha || github.sha }} + run: | + set -euo pipefail + curl -sSfL "https://github.com/gitleaks/gitleaks/releases/download/v${GITLEAKS_VERSION}/gitleaks_${GITLEAKS_VERSION}_linux_x64.tar.gz" \ + | tar -xz gitleaks + base="$BASE_SHA" + # A branch's first push reports an all-zero "before", and a force-push + # can report a sha this clone no longer has. Both would otherwise make + # the range unresolvable. + if [ "$base" = "0000000000000000000000000000000000000000" ] \ + || ! git cat-file -e "${base}^{commit}" 2>/dev/null; then + base="${HEAD_SHA}~1" + fi + range="${base}..${HEAD_SHA}" + # gitleaks exits 0 on an empty range — it scans nothing and reports + # success, which is indistinguishable from a clean scan. Verified + # against 8.30.1 before writing this. Count the commits ourselves and + # refuse to call zero a pass. + n=$(git rev-list --count "$range") + echo "gitleaks: scanning $n commit(s) in $range" + if [ "$n" -eq 0 ]; then + echo "::error::empty scan range $range — refusing to report a pass" + exit 1 + fi + ./gitleaks git . --log-opts="$range" --redact --no-banner --exit-code 1 - name: Setup Node.js uses: actions/setup-node@v7