Skip to content

ci: verify the repo brew and clone install from [v1.8.4] - #6

Merged
UttyWotty merged 2 commits into
developfrom
feature/ci
Aug 3, 2026
Merged

UttyWotty merged 2 commits into
developfrom
feature/ci

Conversation

@UttyWotty

Copy link
Copy Markdown
Collaborator

This repository is what brew install opsentry and git clone actually pull from — and nothing verified it. There were no workflows at all, only issue and PR templates.

What now runs on every push and PR

step why
hook test suite 168 assertions across the 8 guardrail hooks, simulating Claude Code's PreToolUse JSON
ruff check opsentry the two Python modules (baseline.py, blocklog_audit.py)
bash -n on install.sh + all 8 hooks install.sh is the git-clone install path; a broken shebang there breaks the documented install for everyone not using brew or pip, and no test would otherwise catch it

All three verified locally first — 168 passed, ruff clean, every script parses.

Why it is self-contained

The rest of the organisation calls a reusable workflow from a private repository. This one does not, deliberately: a contributor opening a pull request must be able to read every step that gates it, and a private workflow would be invisible to them. It also avoids a public repository depending on a private one to verify itself.

Context

Part of making this repository the authoritative source for the free product. Related: homebrew-opsentry v0.1.2 bumped the formula from a two-release-old v1.8.0 tarball to v1.8.3, so brew install and git clone now agree.

🤖 Generated with Claude Code

This repository is what `brew install opsentry` and `git clone` pull from, and
nothing verified it -- there were no workflows at all, only issue and PR
templates. Every push and pull request now runs the 168-assertion hook suite,
lints the Python, and syntax-checks install.sh plus all eight guardrail hooks so
a broken installer cannot ship.

The workflow is self-contained rather than calling the organisation's shared
one, which lives in a private repository. A contributor opening a pull request
must be able to read every step that gates it, and a private workflow would be
invisible to them.
CI caught it on its first run: baseline.py and blocklog_audit.py carry
#!/usr/bin/env python3 but were tracked 100644, so neither could be run directly
despite advertising that it could. Both are invoked via python3 today, so the
bit was cosmetic -- but a shebang that does not work is a claim the file does
not honour, and fixing it is better than suppressing the check that found it.

ruff is pinned in CI because its default rule set grows between releases, and an
unpinned upgrade would fail a commit that changed nothing.
@UttyWotty
UttyWotty merged commit 585a3f5 into develop Aug 3, 2026
1 check passed
@UttyWotty
UttyWotty deleted the feature/ci branch August 3, 2026 09:03
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