Skip to content

fix: install git-scrub with the contributor toolchain - #70

Open
catinspace-au wants to merge 1 commit into
mainfrom
fix/add-git-scrub-to-contributor
Open

fix: install git-scrub with the contributor toolchain#70
catinspace-au wants to merge 1 commit into
mainfrom
fix/add-git-scrub-to-contributor

Conversation

@catinspace-au

Copy link
Copy Markdown
Contributor

We use git-scrub to rewrite AI residue and leaked secrets out of git history, but nothing in the installer ever put it on a box, so everyone was fetching it by hand.

It goes in contributor, not soe, because it is what clears a gitleaks failure and gitleaks scans FULL history: a secret removed from HEAD still fails the gate. soe inherits it through meta/dependencies. Snipeable on its own with --tags git-scrub.

GitHub release tarball on every platform. That is the only rung going:

  • not on crates.io
  • downloads.hyperi.io serves no git-scrub path (404)
  • the release ships a git-scrub.rb that is not in our tap yet, so macOS takes the darwin asset until someone taps it

The tarball is KEPT rather than deleted, and that is what makes the role idempotent - get_url re-reports ok for an unchanged asset, so the extract and install stay skipped on a converged box. We cannot ask the binary its version instead, because v1.0.2 reports itself as "git-scrub 1.0.1".

Done when git-scrub installs on a fresh box, a second run is all green, and the docs match.

Verified

  • ansible-lint on the new file: 0 failures, production profile
  • --syntax-check: ok
  • --check run of the tag: failed=0, rescued=0
  • two consecutive LIVE runs: run 1 installs, run 2 reports download ok with extract/install/cleanup all skipping
  • git-scrub --version runs from /usr/local/bin
  • tools/ci/run-tests.sh: all available checks passed

Not verified

  • macOS and Fedora. Only Ubuntu 26.04 amd64 was exercised - I have no Mac or Fedora box in reach. The asset naming is the same shape on all three, but the darwin path is untested.

Known and left alone

  • register: verify_git_scrub trips var-naming[no-role-prefix]. Its three neighbours in that file trip the identical rule, so I kept the local convention rather than being the odd one out. Fixing all four is a separate tidy-up.
  • hyperi-ci check fails with "Could not detect project language" on this branch AND on clean main, so it is pre-existing, not this change.

We use git-scrub to rewrite AI residue and leaked secrets out of git
history, but nothing in the installer put it on a box -- everyone was
fetching it by hand.

It goes in contributor rather than soe because it is what clears a
gitleaks failure, and gitleaks scans full history: a secret removed from
HEAD still fails the gate. soe inherits it through meta/dependencies.
Snipeable on its own with --tags git-scrub.

GitHub release tarball on every platform. That is the only rung going --
it is not on crates.io, downloads.hyperi.io serves no git-scrub path, and
the release ships a git-scrub.rb that is not in our tap yet, so macOS
takes the darwin asset until someone taps it.

The tarball is kept rather than deleted, and that is what makes the role
idempotent: get_url re-reports ok for an unchanged asset so the extract
and install stay skipped on a converged box. We cannot ask the binary its
version instead -- v1.0.2 reports itself as "git-scrub 1.0.1".
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant