Skip to content

ci: vendor governance-enforce — this repo was never in the A_BLOCK ruleset - #20

Open
yakimoto wants to merge 3 commits into
mainfrom
ci/vendor-governance-enforce
Open

ci: vendor governance-enforce — this repo was never in the A_BLOCK ruleset#20
yakimoto wants to merge 3 commits into
mainfrom
ci/vendor-governance-enforce

Conversation

@yakimoto

@yakimoto yakimoto commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

Adds the governance-enforce A_BLOCK gate (secrets / hardcoded-paths, diff-scoped) to this repo. Pilot of claude-workstation#1624 E4 T4.9a — the other four package origins follow once this one is observed green.

Why this repo had no secrets scan

The org ruleset governance-a-block-enforce (17901847) requires an enforce check across the fleet. Its scope is an explicit include list of 112 hand-maintained repository names — and every one of them matches wave-*.

The 16 public repos absent from that list are exactly the 16 not named wave-*. That set is .github, adk, api-spec, cli, companion-module-wave, create-wave-app, crest-console, dispatch-edge, examples, mcp-server, obs-wave-plugin, sdk, sdk-python, sdks, vmix-wave-integration, workflow-sdk.

Read the intersection: the repos that publish our npm packages are precisely the repos running with no A_BLOCK secrets scan. Nobody excluded them. A naming convention silently became a security boundary, and it drew the line in the worst possible place.

Why the workflow lands before the ruleset entry

Adding a repo to a required_status_checks ruleset before it emits that check is a permanent deadlock — a required check that never reports can never go green, and every PR on the repo becomes unmergeable. So the order is: vendor the workflow, observe it green, then extend the list. Doing it the intuitive way round would have bricked all sixteen.

This PR is therefore its own liveness drill. The workflow triggers on pull_request, so it runs on the PR that adds it. If enforce reports green here, the vendored shape works on a public repo. If it does not, nothing was required and nothing is blocked — which is the whole point of this ordering.

Why this shape

Copied verbatim from wave-av/wave-moq-edge, which is public and 12/12 green — so the shape is proven on a public repo rather than inferred from a private one. That distinction matters here: auto-approve.yml fails silently on every public repo because it calls a reusable workflow in the private wave-foundation, and a public repo cannot do that (parse-time failure, zero jobs, no annotation). This workflow calls nothing cross-repo, so that trap does not apply.

Security properties, unchanged from the source:

  • actions SHA-pinned (actions/checkout@df4cb1c, actions/setup-node@48b55a0)
  • persist-credentials: false on checkout
  • least privilege: contents: read + packages: read
  • isolated install into RUNNER_TEMP, --no-save, so nothing touches this repo's dependency tree
  • the .npmrc is written with a literal ${NODE_AUTH_TOKEN} (single-quoted printf) which npm expands at run time — no secret value is ever written to disk or a log
  • both ${{ }} inputs (base.sha, event.before) are routed through env: and read as "$VAR", never interpolated into the script body

Diff-scoped by design: it blocks new violations without failing on legacy debt.

The one assumption being tested

@wave-av/governance is an internal-visibility package owned by claude-workstation. wave-moq-edge is public and reads it fine, but rather than fan out on that inference, this PR pilots a single repo. Green here means the remaining four (sdk, adk, mcp-server, workflow-sdk) follow immediately.

Refs wave-av/claude-workstation#1624.


Open in Devin Review

Review in cubic


Note

Low Risk
CI-only change with no application runtime impact; main operational risk is workflow misconfiguration (e.g. required check before green runs), which the PR explicitly sequences to avoid.

Overview
Adds governance-enforce.yml, a new GitHub Actions workflow that runs on pull requests and pushes to main/master. It installs a pinned @wave-av/governance@0.4.6 into an isolated temp directory and runs enforce.mjs against the PR or push diff (not the full tree on the happy path), targeting A_BLOCK rules: secrets in git, Doppler sourcing, and hardcoded paths.

The workflow is hardened so the gate cannot report green without actually scanning files: registry token only on the npm install step, --ignore-scripts, push-run concurrency that does not cancel in-progress scans, unreachable diff bases validated with git cat-file, and a fail-closed fallback to the empty tree when no base SHA exists (instead of diffing HEAD against itself).

This is a pilot for repos outside the org governance-a-block-enforce ruleset (non-wave-* names like cli). The PR description notes the ruleset entry should wait until enforce is observed green here.

Reviewed by Cursor Bugbot for commit 3614200. Configure here.

Note

Add governance enforcement workflow to scan diffs on PRs and pushes to main

Adds governance-enforce.yml, which runs @wave-av/governance@0.4.6 on pull requests, merge groups, and pushes to main/master. The enforcer scans only changed files using a computed diff base; if no valid base is found, it falls back to the empty tree and scans the full repository. Push and merge group runs are not cancelable to ensure no committed ranges are skipped.

Macroscope summarized a3dbfa9.

@yakimoto yakimoto added the rr:skip-cubic RF.P1 reviewer routing (#1039) label Aug 5, 2026
@coderabbitai

coderabbitai Bot commented Aug 5, 2026

Copy link
Copy Markdown

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 44 minutes

Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 4e9bb6e7-f8cf-402e-8cef-04a651167018

📥 Commits

Reviewing files that changed from the base of the PR and between 80d078b and a3dbfa9.

📒 Files selected for processing (1)
  • .github/workflows/governance-enforce.yml

Comment @coderabbitai help to get the list of available commands.

@cursor

cursor Bot commented Aug 5, 2026

Copy link
Copy Markdown

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_997a5149-7139-4425-adf3-bd4c96533cb6)

@qodo-code-review

Copy link
Copy Markdown

PR Summary by Qodo

CI: add vendored governance-enforce A_BLOCK diff gate

✨ Enhancement ⚙️ Configuration changes 🕐 10-20 Minutes

Grey Divider

AI Description

• Add a GitHub Actions workflow that enforces A_BLOCK (secrets + hardcoded paths) on PR diffs.
• Run the gate on pull requests and on pushes to main/master to ensure continuous coverage.
• Use SHA-pinned actions and an isolated npm install from GitHub Packages with least privilege.
Diagram

graph TD
  A("PR / Push") --> B["GitHub Actions: governance-enforce"] --> C["Checkout (no creds)"] --> D["Setup Node 22"] --> E["Install @wave-av/governance (RUNNER_TEMP)"] --> F["Run enforce.mjs --changed BASE"]
  E --> G["GitHub Packages (npm.pkg.github.com)"]
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Publish a shared composite action (public)
  • ➕ Centralizes updates so all repos inherit fixes without re-vendoring
  • ➕ Avoids cross-repo reusable-workflow limitations for public repos if action repo is public
  • ➖ Requires creating/maintaining an action repo and release process
  • ➖ Still needs per-repo wiring and permissions review
2. Enforce via GitHub Advanced Security secret scanning + rules
  • ➕ Native platform scanning and alerting; no custom npm install in CI
  • ➕ Less operational complexity once enabled org-wide
  • ➖ May not match the org’s custom A_BLOCK policy checks (e.g., hardcoded paths)
  • ➖ Diff-scoped “block new violations only” behavior may be harder to replicate exactly

Recommendation: The vendored workflow is the right near-term approach given the explicit goal: emit an 'enforce' check without depending on private cross-repo workflows (which can fail silently on public repos). If this expands to multiple public package repos, consider migrating the exact same logic into a public composite action to reduce drift and simplify updates while keeping the same security posture.

Files changed (1) +59 / -0

Other (1) +59 / -0
governance-enforce.ymlAdd governance-enforce A_BLOCK diff-scoped enforcement workflow +59/-0

Add governance-enforce A_BLOCK diff-scoped enforcement workflow

• Introduces a new GitHub Actions workflow that runs on pull requests and pushes to main/master. It installs @wave-av/governance into RUNNER_TEMP using a token-scoped .npmrc, then runs the enforcer against the computed base SHA to block new secrets/hardcoded-path violations. Actions are SHA-pinned and permissions are limited to contents/packages read.

.github/workflows/governance-enforce.yml

@macroscopeapp

macroscopeapp Bot commented Aug 5, 2026

Copy link
Copy Markdown

Approvability

Verdict: Needs human review

Unable to check for correctness in a3dbfa9. Adds a new CI security governance workflow that gates PRs and pushes on secrets scanning. While thoughtfully designed with fail-closed semantics, new security gate infrastructure warrants human review to validate the enforcement logic and confirm operational readiness (e.g., no legacy debt blocking fallback scenarios).

You can customize Macroscope's approvability policy. Learn more.

macroscopeapp[bot]
macroscopeapp Bot previously approved these changes Aug 5, 2026
devin-ai-integration[bot]

This comment was marked as resolved.

@qodo-code-review

qodo-code-review Bot commented Aug 5, 2026

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

Grey Divider


Remediation recommended

1. Enforcer version floats ✓ Resolved 🐞 Bug ⛨ Security
Description
The workflow installs @wave-av/governance using the semver range ^0.4.4, so the enforcement
implementation can change between runs without any PR to this repo. That makes the required gate
non-reproducible and can cause sudden CI/policy changes or breakage when a new compatible version is
published.
Code

.github/workflows/governance-enforce.yml[R47-49]

+          printf '@wave-av:registry=https://npm.pkg.github.com\n//npm.pkg.github.com/:_authToken=${NODE_AUTH_TOKEN}\n' > .npmrc
+          npm install @wave-av/governance@^0.4.4 --no-save --no-audit --no-fund
+      - name: A_BLOCK enforce (secrets + hardcoded paths on the diff)
Evidence
The workflow explicitly installs the enforcer with a floating semver range, while other repo gates
emphasize pinned/verified tooling for determinism.

.github/workflows/governance-enforce.yml[44-49]
.github/workflows/public-repo-guard.yml[9-14]
.github/workflows/public-repo-guard.yml[47-60]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The workflow installs `@wave-av/governance` with a caret range (`^0.4.4`), which allows the enforcer behavior to change without any change to this repository.

### Issue Context
This workflow is intended to act as an enforcement gate. For gates, reproducibility is important so that a given commit is evaluated consistently.

### Fix Focus Areas
- .github/workflows/governance-enforce.yml[44-49]

### Suggested change
- Change `npm install @wave-av/governance@^0.4.4 ...` to an exact version (e.g. `@0.4.4`).
- If controlled upgrades are desired, bump the pinned version via PR when you want to roll forward.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Fork PR package access risk 🐞 Bug ☼ Reliability
Description
The pull_request workflow requires downloading @wave-av/governance from GitHub Packages using
NODE_AUTH_TOKEN=${{ secrets.GITHUB_TOKEN }}; forked PR runs will only succeed if that token has read
access to the package in this context, otherwise npm install fails and the check reports red. Since
this repository is explicitly operated as public, this can block outside contributors once the check
is made required.
Code

.github/workflows/governance-enforce.yml[R18-21]

+on:
+  pull_request:
+  push:
+    branches: [main, master]
Evidence
The workflow is triggered on pull_request and attempts to install from npm.pkg.github.com using
GITHUB_TOKEN; existing workflows explicitly describe this repo as public, making fork PRs a relevant
execution mode.

.github/workflows/governance-enforce.yml[18-26]
.github/workflows/governance-enforce.yml[34-48]
.github/workflows/foundation-gate.yml[3-6]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The workflow runs on `pull_request` and fetches `@wave-av/governance` from GitHub Packages using `GITHUB_TOKEN`. In public repos, fork PRs commonly differ in what the token can access; if the package isn't readable in that context, the install step will fail and the gate will be unavailable for forks.

### Issue Context
This repo is explicitly treated as PUBLIC by existing workflows, so fork PRs are a realistic scenario.

### Fix Focus Areas
- .github/workflows/governance-enforce.yml[18-48]

### Suggested change (pick one)
1) Ensure `@wave-av/governance` is readable in fork-PR contexts (package visibility/access settings), and add a small self-check with a clear error message if it isn't.
2) Add explicit fork handling (e.g., conditionally skip with a clear message) *only if* this check will not be required for forks.
3) If you need this required for forks too, adjust the workflow design so it can run without depending on private package access from fork PRs (e.g., make the enforcer available without auth, or vendor a pinned artifact).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Informational

3. BASE SHA not validated ✓ Resolved 🐞 Bug ☼ Reliability
Description
On push events, BASE is set from github.event.before but is only special-cased for empty/all-zero;
it is never validated to exist in the local checkout before being passed to the enforcer. If the
before-SHA is not present (e.g., history rewrites/non-fast-forward updates), the enforcement step
can fail due to an invalid diff base.
Code

.github/workflows/governance-enforce.yml[R54-57]

+          BASE="${PR_BASE_SHA:-$PUSH_BEFORE_SHA}"
+          if [ -z "$BASE" ] || [ "$BASE" = "0000000000000000000000000000000000000000" ]; then
+            BASE=$(git rev-parse HEAD~1 2>/dev/null || git rev-parse HEAD)
+          fi
Evidence
The workflow sets BASE from PR base SHA or push "before" SHA, but only falls back when BASE is empty
or the all-zero sentinel; it does not check that git can resolve BASE before invoking the enforcer.

.github/workflows/governance-enforce.yml[49-59]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The script computes `BASE` for `--changed` but doesn't confirm the SHA resolves locally. A nonempty-but-missing SHA can break the gate run.

### Issue Context
This is primarily an edge case for unusual push shapes (e.g., rewritten history), but adding a small validation makes the workflow more robust.

### Fix Focus Areas
- .github/workflows/governance-enforce.yml[51-59]

### Suggested change
- After computing `BASE`, add a check like `git cat-file -e "$BASE^{commit}"` and if it fails, fall back to `HEAD~1` (or another safe baseline) with a log line explaining the fallback.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Context used
✅ Compliance rules (platform): 2 rules
Review mode: ⚖️ Balanced: This adds a security-sensitive CI enforcement workflow with GitHub permissions, token handling, dependency installation, and diff-base logic; a single localized hunk still warrants a careful standard review.

To customize comments, go to the Qodo configuration screen, or learn more in the docs.

Qodo Logo

qodo-code-review[bot]

This comment was marked as resolved.

@qodo-code-review

Copy link
Copy Markdown

Qodo Fixer

No findings are within the configured fix scope. To change which findings are fixed, adjust the setting on your Qodo configuration page.

cubic-dev-ai[bot]

This comment was marked as resolved.

…othing

Five defects, none of them cosmetic. Refs wave-av/claude-workstation#1747.

1. FAIL-OPEN DIFF BASE. `BASE=$(git rev-parse HEAD~1 2>/dev/null || git rev-parse HEAD)`
   — on a root commit `git rev-parse HEAD~1` prints its unresolved argument to stdout AND
   fails, so the `||` branch appends and BASE becomes a two-line string. `git diff` then
   exits 128, and the pinned enforcer turned that into zero files and a green check. Now:
   a reachability-checked base (a force-push can leave `github.event.before` pointing at a
   commit this checkout does not have), and with no resolvable base at all it diffs against
   the EMPTY TREE so the whole repo is scanned rather than nothing.

2. THE PINNED ENFORCER ITSELF FAILED OPEN. `^0.4.4` resolved to 0.4.4, whose file lister is
   `catch { return []; }` — any git error became zero files and rendered as
   `OK[enforce]: 0 changed file(s) scanned — 0 A_BLOCK violations`. A git error and a clean
   diff were byte-identical in the output. The fix had sat unreleased on claude-workstation
   main since 2026-07-29 because no `governance-v*` tag was ever pushed. Released now as
   0.4.6 and pinned exactly here.

3. TOKEN IN SCOPE FOR THE WRONG STEPS. `NODE_AUTH_TOKEN` was job-level, so it was also in
   the environment of the step that executes the downloaded package. Now step-scoped, and
   the .npmrc holding it is removed on exit.

4. INSTALL SCRIPTS RAN WITH THAT TOKEN. `npm install` runs preinstall/postinstall by
   default. Added `--ignore-scripts`.

5. CANCELLED PUSH RUNS WERE SCANNED BY NOBODY. `cancel-in-progress: true` applied to push
   runs, and each push run only diffs its own before..HEAD range — so a cancelled run's
   commits were never examined by anything. Now PR-only.

Also: `timeout-minutes: 10` and `set -euo pipefail`.

Receipt, against a scratch repo whose root commit carries a no-hardcoded-paths violation,
simulating a branch-creation push (`before` = all zeros):
  old logic -> malformed base -> caught error -> [] -> OK, 0 files scanned, PASS
  new logic -> "no diff base resolved ... scanning the whole tree" -> BLOCK, exit 1

Credit where it is due: several of these were found by the review bots on the sibling
vendoring PRs and are folded in here — the step-scoped token, the .npmrc cleanup, the exact
pin, `--ignore-scripts`, the force-push reachability check, `timeout-minutes`, and the
concurrency hole (5), which was crest-console#7's catch and which I had missed entirely.
@cursor

cursor Bot commented Aug 6, 2026

Copy link
Copy Markdown

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_29992160-7c70-494b-8f6f-840cead67d07)

# A base can be PRESENT and still unusable: a force-push leaves `github.event.before`
# pointing at a commit this checkout no longer contains.
if [ -z "$BASE" ] || [ "$BASE" = "0000000000000000000000000000000000000000" ] \
|| ! git cat-file -e "$BASE^{commit}" 2>/dev/null; then

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟠 High workflows/governance-enforce.yml:79

When PUSH_BEFORE_SHA is missing or unreachable (force-push, initial multi-commit push), the fallback resolves BASE to HEAD~1, so the scan only diffs the final commit against its immediate parent. Any earlier commits bundled into that same push are skipped entirely, letting a secret or hardcoded path introduced in one of those earlier commits land without this gate examining it. Consider walking back to the oldest commit still reachable from HEAD that is outside the target branch's existing history (e.g., via git rev-list against the remote tracking ref or merge-base), or scanning the full tree when a reliable base cannot be resolved.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
In file @.github/workflows/governance-enforce.yml around line 79:

When `PUSH_BEFORE_SHA` is missing or unreachable (force-push, initial multi-commit push), the fallback resolves `BASE` to `HEAD~1`, so the scan only diffs the final commit against its immediate parent. Any earlier commits bundled into that same push are skipped entirely, letting a secret or hardcoded path introduced in one of those earlier commits land without this gate examining it. Consider walking back to the oldest commit still reachable from `HEAD` that is outside the target branch's existing history (e.g., via `git rev-list` against the remote tracking ref or merge-base), or scanning the full tree when a reliable base cannot be resolved.

Evidence trail:
.github/workflows/governance-enforce.yml:67-93 at 3614200
.git diff MERGE_BASE REVIEWED_COMMIT -- .github/workflows/governance-enforce.yml

@devin-ai-integration devin-ai-integration Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Devin Review found 2 new potential issues.

Open in Devin Review

Comment thread .github/workflows/governance-enforce.yml Outdated
Comment on lines +88 to +91
if [ -z "$BASE" ]; then
BASE="$(git hash-object -t tree /dev/null)"
echo "::notice::no diff base resolved (root commit or unreachable before-sha) — scanning the whole tree against the empty tree"
fi

@devin-ai-integration devin-ai-integration Bot Aug 6, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔍 Whole-tree fallback can fail on legacy debt, contradicting the diff-scoped promise

The empty-tree fallback makes every tracked file read as added, so on a root-commit push (or an unresolvable base) the gate scans the entire repository. That is deliberately fail-closed, but it means a run can fail on pre-existing violations the diff-scoped design explicitly promises not to block on. Worth confirming this repo currently has zero A_BLOCK findings on a full-tree scan before the check is added to governance-a-block-enforce, otherwise a rare fallback would produce an unmergeable PR.

Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

…l a false pass

Correction to the previous commit on this branch. Refs wave-av/claude-workstation#1747.

That commit replaced the fail-open `BASE=HEAD` with a fallback to `HEAD~1`. `HEAD~1` is
also wrong: it scans exactly ONE commit, so a five-commit push whose base is indeterminate
(branch creation, force-push, unreachable `github.event.before`) examines the last commit
and reports a confident pass on the other four. A narrowed scan reported as a full pass is
the same defect in a quieter costume.

Receipt — scratch repo, five-commit push, violation planted in commit 1:
  HEAD~1 base      -> OK[enforce]: 1 changed file(s) scanned  -> PASS   (never saw it)
  empty-tree base  -> 5 changed file(s) scanned -> BLOCK[enforce]: no-hardcoded-paths, exit 1

Now: with no resolvable base of any kind, diff against git's empty-tree object so every
tracked file reads as added and the whole repo is scanned. Loud, never partial, never empty.

Credit: wave-av/wave-rig's copy on main already had this right, with the reasoning in a
comment ("HEAD~1 would skip earlier commits in a multi-commit push and let a violation
through"). The fan-out copied the broken shape from elsewhere and I did not check the one
repo that had already solved it.

Also from wave-rig: `merge_group` is now a declared trigger and `github.event.merge_group.
base_sha` joins the base chain. None of these repos runs a merge queue today, so the trigger
is inert — but a required check that never reports on an event the repo actually uses is a
permanent deadlock, and this closes that in advance rather than after someone hits it.

@devin-ai-integration devin-ai-integration Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Devin Review found 1 new potential issue.

Open in Devin Review

Comment on lines +101 to +107
if [ -z "$BASE" ] || [ "$BASE" = "0000000000000000000000000000000000000000" ] \
|| ! git cat-file -e "$BASE^{commit}" 2>/dev/null; then
BASE="$(git hash-object -t tree /dev/null)"
echo "::warning::indeterminate diff base (root commit, branch creation, or unreachable before-sha) — scanning the full tree against the empty-tree object so no commit is skipped"
fi
echo "diffing against $BASE"
exec node "$ENFORCE" --changed "$BASE"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔍 Empty-tree fallback depends on the enforcer accepting a tree object as a diff base

The fallback sets BASE to the empty-tree object hash and passes it to --changed. This only works if @wave-av/governance@0.4.6 diffs with two-dot/tree-capable semantics (e.g. git diff --name-only <base> HEAD). If the enforcer internally uses three-dot syntax (git diff base...HEAD) or git merge-base, a tree object is not a valid argument and the step would error out rather than scanning the whole tree. Since the package is private and not vendored here, this cannot be verified from the repo; worth confirming once against a force-push / new-branch scenario before making the check required (the header comment already advises observing it green first).

Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

rr:skip-cubic RF.P1 reviewer routing (#1039)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant