Description

In agent-tools-build.yml, the new “non-blocking” Trivy report step ignores Trivy failures ("||
true") but then runs an unguarded jq ... | head pipeline; if Trivy produces empty/invalid JSON,
jq can fail and block the workflow anyway. This can prevent later steps (including publish) from
running even though the step is intended to be report-only.

Code

.github/workflows/agent-tools-build.yml[R197-200]

+            echo "Strict gate is on hoophq/hoopdev-minimal. Top packages:"
+            echo '```'
+            jq -r '[.Results[]?.Vulnerabilities // []]|add|group_by(.PkgName)|map({p:.[0].PkgName,c:length})|sort_by(-.c)|.[]|"\(.c)\t\(.p)"' trivy-vuln.json 2>/dev/null | head -20
+            echo '```'

Relevance

●●● Strong

Non-blocking step should never fail; guarding jq/head is small deterministic workflow-hardening.

PR-#1595 PR-#1619

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The step intentionally ignores Trivy failures when writing trivy-vuln.json, but then immediately
runs a jq pipeline (without any fallback) to render the "Top packages" list; this can still fail
if the JSON file is empty/invalid. The same pattern is duplicated in the arm64 job.

.github/workflows/agent-tools-build.yml[179-201] .github/workflows/agent-tools-build.yml[300-318]

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 Trivy step is explicitly labeled/report-only and uses `|| true` to avoid failing when Trivy errors, but the subsequent `jq ... | head` command is not guarded. If `trivy-vuln.json` is empty or invalid (e.g., Trivy fails before producing valid JSON), `jq` may exit non-zero and the step can still fail.

## Issue Context
This occurs in both amd64 and arm64 jobs in `agent-tools-build.yml`.

## Fix Focus Areas
- .github/workflows/agent-tools-build.yml[185-201]
- .github/workflows/agent-tools-build.yml[302-318]

## Suggested fix approach
- Make the "Top packages" rendering resilient, e.g.:
 - Wrap it in a conditional JSON validity check (`jq -e . trivy-vuln.json >/dev/null 2>&1`) and print a fallback message when invalid; and/or
 - Append `|| true` to the `jq ... | head` pipeline.
- Also consider making the count query robust to empty `.Results` by using `add // []` (or similar) so it produces `0` instead of `null` when appropriate.

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

Description

The new blocking govulncheck job requires checking out hoophq/libhoop using secrets.GH_TOKEN; if
that secret is not available in a given PR context, the checkout/build will fail and block merges.
This adds/strengthens a cross-repo access contract between this repo’s PR CI and the libhoop repo’s
availability/permissions.

Code

.github/workflows/pullrequest.yml[R328-331]

+          repository: hoophq/libhoop
+          path: "./libhoop"
+          token: ${{ secrets.GH_TOKEN }}
+          ref: ${{ needs.resolve-libhoop.outputs.sha }}

Relevance

●●● Strong

They’ve accepted adding explicit checks around required secrets to avoid late workflow failures.

PR-#1595

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The newly-added govulncheck job checks out hoophq/libhoop using secrets.GH_TOKEN, and the
workspace includes ./libhoop, meaning the job’s success depends on successfully fetching that
separate repository/module. This is an explicit cross-repo auth/availability dependency introduced
into the PR merge gate.

.github/workflows/pullrequest.yml[3-4] .github/workflows/pullrequest.yml[27-41] .github/workflows/pullrequest.yml[309-331] go.work[1-16] External repo: hoophq/libhoop, go.mod [1-4]

Agent prompt

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

### Issue description
`govulncheck` is now a blocking PR job and it checks out `hoophq/libhoop` using `secrets.GH_TOKEN`. If `GH_TOKEN` is missing/unavailable for a PR run (common in fork PR scenarios), the gate will fail before analysis.

### Issue Context
The workflow uses `on: pull_request`, and both `resolve-libhoop` and `govulncheck` rely on `secrets.GH_TOKEN` to access libhoop.

### Fix Focus Areas
- .github/workflows/pullrequest.yml[3-4]
- .github/workflows/pullrequest.yml[27-41]
- .github/workflows/pullrequest.yml[309-331]
- go.work[1-16]

### Suggested change
Implement one of the following patterns:
1) **Conditional gate**: only run `govulncheck` (or only the libhoop checkout step) when `secrets.GH_TOKEN` is present, and otherwise skip the job with a clear message.
2) **OSS stub fallback**: when libhoop checkout cannot run, create `./libhoop` by symlinking to `./_libhoop` (or running the existing mapping target) so govulncheck can still compile against the OSS stub.
3) If `hoophq/libhoop` is intended to be publicly readable for CI, remove the hard dependency on `secrets.GH_TOKEN` for checkout and use a standard token/unauthenticated checkout.

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

Description

The new blocking govulncheck job compiles against the libhoop revision resolved at workflow runtime
(default-branch HEAD when no paired branch), so re-running the same Hoop PR commit can start failing
due to new changes/vulns in hoophq/libhoop. This increases cross-repo coupling and reduces CI
reproducibility across reruns.

Code

.github/workflows/pullrequest.yml[R328-331]

+          repository: hoophq/libhoop
+          path: "./libhoop"
+          token: ${{ secrets.GH_TOKEN }}
+          ref: ${{ needs.resolve-libhoop.outputs.sha }}

Relevance

●● Moderate

Reproducibility vs tracking latest libhoop is a policy trade-off; no close pinning precedent found.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR workflow’s resolve-libhoop job explicitly falls back to the current default-branch
checkout’s HEAD when there is no paired branch, and the newly-added govulncheck job checks out
libhoop at that resolved SHA. The workspace expects a local ./libhoop module, and libhoop is an
independent Go module in a separate repository, so its moving default-branch state can change the
dependency graph analyzed by govulncheck across reruns.

.github/workflows/pullrequest.yml[27-77] .github/workflows/pullrequest.yml[309-348] go.work[1-16] External repo: hoophq/libhoop, go.mod [1-4]

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 `govulncheck` merge gate checks out and compiles against `hoophq/libhoop` using a SHA that can resolve to the libhoop default branch HEAD when no paired branch exists. This makes Hoop PR results dependent on a moving external repo state and can cause the same PR commit to pass/fail depending on when the workflow is run.

### Issue Context
- `resolve-libhoop` falls back to the default-branch checkout’s current `HEAD` when a same-named paired branch does not exist.
- `govulncheck` then checks out that resolved SHA and compiles the workspace (which includes `./libhoop`).

### Fix Focus Areas
- .github/workflows/pullrequest.yml[27-77]
- .github/workflows/pullrequest.yml[309-348]
- go.work[1-16]

### Suggested change
- Introduce an immutable, Hoop-repo-controlled fallback libhoop revision for the “no paired branch” case (e.g., a committed `LIBHOOP_SHA` file or workflow variable), and have `resolve-libhoop` use that pinned SHA instead of “whatever HEAD is today”.
- Keep the paired-branch behavior as-is for coordinated cross-repo changes.

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

💡 Did you know, you can enable the Remediation agent and Qodo fixes findings in a dedicated fix PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗