test(hack): add mint-access-patterns harness for workflow-host policy by ifireball · Pull Request #6918 · fullsend-ai/fullsend

ifireball · 2026-09-02T14:42:49Z

Summary

Add hack/mint-access-patterns.sh, a bash harness that exercises mint repos-field and workflow-host access patterns via GHA OIDC (ADR 0082).
Supports --mode per-repo|per-org|both, optional --project enrollment, --role filter, and foreign e2e cases against staging/dev/public/Cloudflare mints.
Reports PASS/FAIL per case from mint-ap-result artifacts; workflows always exit green so failures surface only in harness output.

Test plan

Staging mint: per-repo, per-org, both — 33/33 each
Dev mint: per-repo, per-org, both — 33/33 each
Cloudflare preview mints (per-org-pv, per-repo-pv, both-pv) — 33/33 parallel
Public mints (mint-test.korren.org, mint.fullsend.sh, mint-status-auth-test.barak-korren.workers.dev) — per-repo without enrollment

Made with Cursor

Exercise mint repos-field and workflow-host access patterns via GHA OIDC (ADR 0082): per-repo, per-org, and both modes with optional enrollment, role filter, and foreign e2e cases. Signed-off-by: Barak Korren <bkorren@redhat.com> Co-authored-by: Cursor <cursoragent@cursor.com>

qodo-code-review · 2026-09-02T14:43:50Z

PR Summary by Qodo

Add mint access-pattern workflow-host policy harness

🧪 Tests 🕐 40+ Minutes

AI Description

• Adds GHA OIDC matrix coverage for repository and workflow-host mint authorization.
• Exercises per-repository, per-organization, combined, role-filtered, and foreign-organization
 scenarios.
• Collects artifact results while keeping generated workflows green to suppress failure
 notifications.

Diagram

sequenceDiagram
  actor User as Operator
  participant Harness as Test Harness
  participant Config as Mint Config
  participant Repo as Fixture Repo
  participant Host as Workflow Host
  participant OIDC as GitHub OIDC
  participant Mint as Mint API
  participant Result as Result Artifact
  User->>Harness: Select mode and role
  opt Project enrollment
    Harness->>Config: Configure enrollment
    Config->>Mint: Apply host policy
  end
  Harness->>Repo: Push ephemeral workflow
  Repo->>Host: Run direct or reusable
  Host->>OIDC: Request identity token
  OIDC-->>Host: Return JWT
  Host->>Mint: Request scoped token
  Mint-->>Host: Mint or deny
  Host->>Result: Upload JSON result
  Harness->>Result: Download result
  Harness-->>User: Report PASS or FAIL

High-Level Assessment

The following are alternative approaches to this PR:

1. Dedicated GitHub Actions workflow

➕ Provides a reusable workflow-dispatch interface and centralized run history
➕ Could parallelize the policy matrix with native matrix jobs
➖ Requires repository-level workflow configuration and credentials
➖ Individual negative cases may create noisy workflow failures unless results remain indirect

2. Go integration-test harness

➕ Offers stronger typing, structured concurrency, and easier unit testing
➕ Could reuse project packages for mint enrollment and result handling
➖ Adds substantial orchestration code for git, gh, and generated workflow interactions
➖ Makes a targeted operational diagnostic harder to inspect and modify quickly

Recommendation: Keep the Bash harness for manual, cross-environment policy validation because its primary work is orchestrating existing command-line tools and generated workflows. If it becomes a required recurring CI gate, migrate the case matrix to a dedicated GitHub Actions workflow or Go harness for parallelism and maintainability.

Files changed (1) +846 / -0

Tests (1) +846 / -0

mint-access-patterns.shAdd end-to-end mint access-pattern policy harness +846/-0

Add end-to-end mint access-pattern policy harness

• Adds a configurable Bash harness that provisions fixture repositories and generated GitHub Actions workflows to test mint authorization across per-repo, per-org, combined, role-specific, and foreign-org cases. It optionally configures mint enrollment, validates minted token scope, retrieves artifact or log results, cleans ephemeral branches, and reports aggregate PASS/FAIL/ERROR status.

hack/mint-access-patterns.sh

fullsend-ai-review · 2026-09-02T14:45:08Z

🤖 Finished Review · ✅ Success · Started 2:45 PM UTC · Completed 3:05 PM UTC

Commit: 05cf421 · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $6.66

qodo-code-review · 2026-09-02T14:45:53Z

Code Review by Qodo

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

1. ~~Help prints executable code~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

The hardcoded help window includes line 40, so --help ends by printing set -euo pipefail as if
it were usage text. Header edits can also silently truncate or expose further implementation lines.

Code

hack/mint-access-patterns.sh[65]
+  sed -n '2,40p' "$0" | sed 's/^# \?//'

Relevance

●●● Strong
Recent accepted precedent flags brittle hardcoded help windows and recommends delimiter-based
extraction.
PR-#6894

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The selected range extends through line 40, which is executable code rather than a comment. A prior
accepted review identified the same brittle fixed-window help pattern in hack scripts.

hack/mint-access-patterns.sh[2-40]
PR-#6894

Agent prompt

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

## Issue description
Replace the fixed help line range with extraction of the header comment block so executable code is never included.

## Issue Context
The comment header ends at line 38, while the current `sed -n '2,40p'` range includes the shell option command on line 40. A delimiter- or comment-prefix-based implementation avoids recurring magic-number maintenance.

## Fix Focus Areas
- hack/mint-access-patterns.sh[2-40]
- hack/mint-access-patterns.sh[64-66]

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

2. per-org extends deprecated mode ✗ Dismissed 📘 Rule violation § Compliance

Description

The new harness adds a dedicated per-org mode with enrollment and expectation behavior for an
installation mode deprecated by ADR 0044. Although the PR description mentions per-org, it neither
identifies the mode as deprecated nor references ADR 0044.

Code

hack/mint-access-patterns.sh[R257-261]

+    per-org)
+      echo "enrollment: unenroll repo ${ORG}/mint-test"
+      fullsend_mint unenroll "${ORG}/mint-test" --project="${GCP_PROJECT}" --region="${GCP_REGION}" --yolo || true
+      echo "enrollment: enroll org ${ORG}"
+      fullsend_mint enroll "${ORG}" --project="${GCP_PROJECT}" --region="${GCP_REGION}"

Relevance

●●● Strong
Recent documentation precedent explicitly accepts identifying per-org mode as deprecated and
referencing ADR 0044.
PR-#5462

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
Compliance rule 2795055 prohibits adding or extending per-org-specific behavior and requires the PR
description to call out deprecated per-org functionality with an ADR 0044 reference. The harness
adds a per-org branch that unenrolls the repository and enrolls the entire organization, while ADR
0044 states that per-org mode is deprecated and should be migrated to per-repo coverage.
Rule 2795055: Flag and avoid changes to deprecated per-org installation mode content (ADR 0044)
hack/mint-access-patterns.sh[257-263]
docs/ADRs/0044-deprecate-per-org-installation-mode.md[297-316]

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 harness introduces dedicated support for deprecated per-org installation mode without the required ADR 0044 callout.

## Issue Context
ADR 0044 makes per-repo the sole future installation mode and requires changes touching per-org behavior to be explicitly identified. Prefer removing the per-org-specific capability; if temporary compatibility testing is necessary, clearly mark it as deprecated and update the PR description to reference ADR 0044.

## Fix Focus Areas
- hack/mint-access-patterns.sh[257-263]

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

3. ~~Failures masquerade as denials~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

The workflow records OIDC failures, network failures, and every non-2xx response—including mint 5xx
errors—as denied. Any negative test therefore passes during an outage or broken OIDC setup instead
of reporting an infrastructure error.

Code

hack/mint-access-patterns.sh[R321-324]

+          if [[ ! "$HTTP_CODE" =~ ^2[0-9][0-9]$ ]]; then
+            echo "Mint denied/failed HTTP $HTTP_CODE"
+            jq -n --arg code "$HTTP_CODE" '{outcome:"denied",http_status:($code|tonumber)}' \
+              > mint-ap-result.json

Relevance

●●● Strong
Recent accepted precedent requires distinguishing GitHub API failures from legitimate empty results
or denials.
PR-#6032

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
OIDC acquisition failure is serialized as denied, and the HTTP path does the same for every
non-2xx status. The driver then declares PASS solely when that outcome equals an expected denied,
so infrastructure failures satisfy all negative cases.
hack/mint-access-patterns.sh[287-325]
hack/mint-access-patterns.sh[708-740]
hack/mint-access-patterns.sh[787-832]

Agent prompt

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

## Issue description
Negative policy tests currently treat OIDC, transport, and server failures as expected denials, allowing broken infrastructure to produce PASS results.

## Issue Context
Only explicit policy rejection responses should produce `outcome:"denied"`. OIDC acquisition failures, curl failures, malformed responses, rate limits, and server errors should produce an error outcome that the driver reports as ERROR.

## Fix Focus Areas
- hack/mint-access-patterns.sh[287-325]
- hack/mint-access-patterns.sh[708-740]

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

View medium (5)

4. ~~Unknown role exits successfully~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

An unrecognized or unrepresented --role value causes every case to return before updating any
counter, after which the harness reports ok 0 and exits successfully. This makes role-filter typos
and valid mint roles absent from this matrix look like successful test runs.

Code

hack/mint-access-patterns.sh[R631-633]

+  if [[ -n "$ROLE_FILTER" && "$role" != "$ROLE_FILTER" ]]; then
+    return 0
+  fi

Relevance

●●● Strong
A role filter yielding zero tests with success is a deterministic harness correctness bug and likely
to be accepted.
ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Filtered-out tests return without incrementing any counter, and the final exit condition only
considers failures and errors. The mint defines additional canonical roles such as scribe and
fix that are not represented in this harness matrix, so even a real role can yield a green
zero-test run.

hack/mint-access-patterns.sh[631-638]
hack/mint-access-patterns.sh[787-845]
internal/mintcore/github.go[69-88]

Agent prompt

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

## Issue description
Ensure `--role` cannot produce a successful run containing zero executed cases.

## Issue Context
Validate the filter against the harness matrix before setup, or track selected/executed cases and exit with a clear usage error when none match.

## Fix Focus Areas
- hack/mint-access-patterns.sh[82-84]
- hack/mint-access-patterns.sh[631-633]
- hack/mint-access-patterns.sh[787-845]

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

5. Real infrastructure identifiers hardcoded 📘 Rule violation ⛨ Security

Description

The harness defaults to named GitHub organizations and an upstream repository that map to real
project infrastructure rather than clearly fake placeholders. Running without overrides can
therefore operate on actual repositories, contrary to the requirement to load environment-specific
identifiers from configuration.

Code

hack/mint-access-patterns.sh[R45-47]
+ORG="fullsand-ai"
+MINT_URL="${FULLSEND_MINT_URL:-}"
+FOREIGN_ORG="halfsend"

Relevance

●●● Strong
Security findings about real environment identifiers in scripts are typically accepted; defaults can
affect live infrastructure.
ⓘ Recommendations generated based on similar findings in past PRs

Evidence
Compliance rule 1062040 disallows real environment-specific identifiers in tests and scripts unless
they are clearly fake placeholders. The new defaults include fullsand-ai, halfsend, and
fullsend-ai/fullsend; repository documentation confirms that the halfsend family is an actively
maintained GitHub organization pool used by live tests.
Rule 1062040: Disallow hardcoded secrets and sensitive environment-specific identifiers in source code
hack/mint-access-patterns.sh[45-55]
docs/ADRs/0040-org-pool-for-parallel-e2e-tests.md[34-43]

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 test harness embeds real organization and repository identifiers as defaults.

## Issue Context
Tests and harnesses must use clearly fake placeholders or require environment-specific identifiers through flags or environment variables. Make operational organization and workflow-host values mandatory configuration instead of silently targeting known infrastructure.

## Fix Focus Areas
- hack/mint-access-patterns.sh[45-55]

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

6. gh bypasses forge.Client 📘 Rule violation ⌂ Architecture

Description

The harness directly creates and queries GitHub repositories through gh, bypassing the required
forge.Client abstraction. This introduces forge-specific operations outside internal/forge and
prevents dependency injection through the project interface.

Code

hack/mint-access-patterns.sh[170]
+  if gh api "/repos/${full}" --silent &>/dev/null; then

Relevance

●●● Strong
Recent precedents accept findings requiring GitHub API access to remain behind approved forge
abstractions.
PR-#4901
PR-#5578

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
Compliance rule 1062052 requires all repository and workflow operations to use forge.Client. The
added ensure_repo implementation calls gh api and gh repo create directly, including a
GitHub-specific organization repository endpoint.
Rule 1062052: Route all git forge operations through forge.Client
hack/mint-access-patterns.sh[167-182]

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 new harness performs GitHub repository operations directly with the `gh` CLI instead of routing them through `forge.Client`.

## Issue Context
Repository lookup and creation are git-forge operations covered by the project abstraction requirement. Add or reuse a Go helper backed by `forge.Client`, and have the harness invoke that helper rather than constructing GitHub-specific commands itself.

## Fix Focus Areas
- hack/mint-access-patterns.sh[167-182]

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

7. ~~Durations accept invalid values~~ ✓ Resolved 🐞 Bug ☼ Reliability

Description

--timeout and --poll-interval accept arbitrary strings and non-positive numbers before being
used in arithmetic and sleep. Malformed input can abort under set -u, while a zero polling
interval creates a tight GitHub API loop until timeout.

Code

hack/mint-access-patterns.sh[R98-104]

+    --timeout)
+      TIMEOUT="${2:?--timeout requires a value}"
+      shift 2
+      ;;
+    --poll-interval)
+      POLL_INTERVAL="${2:?--poll-interval requires a value}"
+      shift 2

Relevance

●● Moderate
Input validation is reliability-relevant, but no closely matching precedent establishes acceptance
for these duration flags.
ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The options are assigned without validation; TIMEOUT is later evaluated arithmetically and
POLL_INTERVAL controls both polling sleeps. Because the script enables nounset and immediate-exit
behavior, malformed arithmetic can terminate abruptly, and zero bypasses throttling.

hack/mint-access-patterns.sh[40-40]
hack/mint-access-patterns.sh[98-104]
hack/mint-access-patterns.sh[578-610]

Agent prompt

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

## Issue description
Validate timeout and polling arguments as positive numeric durations before starting setup or API calls.

## Issue Context
`TIMEOUT` is evaluated in Bash arithmetic, and `POLL_INTERVAL` is passed directly to `sleep`. Invalid values should produce a clear usage error rather than an arithmetic failure, immediate timeout, or busy polling loop.

## Fix Focus Areas
- hack/mint-access-patterns.sh[98-104]
- hack/mint-access-patterns.sh[118-130]
- hack/mint-access-patterns.sh[578-610]

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

8. ~~Minted scope accepts supersets~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

Scope validation only checks that granted_repos contains the expected repository and never
verifies exact repositories or role permissions. Over-broad or incorrectly permissioned tokens can
therefore be reported as PASS, while the foreign wildcard minted case performs no scope validation
at all.

Code

hack/mint-access-patterns.sh[R361-363]

+            if ! jq -e --arg want "$EXPECTED_SCOPE_REPO" \
+              '.granted_repos | index($want) != null' mint-ap-result.json >/dev/null; then
+              echo "Expected granted_repos to contain $EXPECTED_SCOPE_REPO, got $REPOS" >&2

Relevance

●● Moderate
Scope correctness is substantial and plausible, but no closely matching historical acceptance or
rejection precedent was found.
ⓘ Recommendations generated based on similar findings in past PRs

Evidence
Mint policy requires per-repo scope to be exactly the requesting repository, and wildcard requests
represent installation-wide scope. The handler returns repositories, permissions, and selection and
merely logs permission discrepancies, but the harness checks only repository membership and passes
foreign wildcard with no expected scope.
internal/mintcore/repos_scope.go[29-36]
internal/mintcore/repos_scope.go[65-72]
internal/mintcore/handler.go[361-394]
hack/mint-access-patterns.sh[336-372]
hack/mint-access-patterns.sh[728-740]
hack/mint-access-patterns.sh[831-832]

Agent prompt

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

## Issue description
Minted cases must verify the complete repository selection, exact repository set, and exact role permissions rather than repository membership alone.

## Issue Context
The mint response exposes all granted scope fields. `repos:["*"]` is normalized to installation-wide scope, so the foreign wildcard case should explicitly assert the corresponding selection and repository shape.

## Fix Focus Areas
- hack/mint-access-patterns.sh[336-372]
- hack/mint-access-patterns.sh[645-647]
- hack/mint-access-patterns.sh[797-832]

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

Context sources

✅ Compliance rules (platform): 65 rules

✅ Skills: writing-user-docs, writing-adrs

Review mode: ⚖️ Balanced: Downgraded extended -> standard: change is below the extended eligibility bar (hunks 1/18, lines 846/200; both must reach the floor). Router rationale: This adds a large, behavior-dense Bash harness spanning GitHub API/git workflows, OIDC token handling, mint authorization assertions, optional cloud enrollment, cleanup, polling, and multiple independent test paths, making subtle defects likely to be missed in one pass.

Tip of the day

💡 Did you know, you can copy the agent prompt from any finding and feed it to your IDE agent

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

fullsend-ai-review · 2026-09-02T15:05:28Z