Adopt go.list as the Go scan target for the Sonatype Lifecycle lane

[ModeSevenIndustrialSolutions]

Context

PR #38 resolves scan_targets to go.sum whenever build_type: 'go', unconditionally and without a caller override, matching the legacy Jenkins gerrit-nexus-iq-go-clm job.

Sonatype's guidance has since moved on.

If PR #38 absorbs this before merge, close this issue. It exists so the follow-up is not lost if #38 merges targeting go.sum only.

Current vendor guidance

Go Application Analysis, last modified 18 Feb 2026 (checked Aug 2026):

go.list — A customer-generated file containing the output of the go list command. This provides the most accurate results because it reflects the dependencies resolved by the Go tooling during build.

go.sum — Supported, but may include dependencies that are not used by the application.

and:

The recommended approach is to generate a go.list file using the go list command. This file should be the target for the Lifecycle scan.

The page repeats the point under "reduce Unknown results": "Use a go.list file generated from your build." It also no longer mentions the CycloneDX/SBOM route for Go at all.

Proposal

Make the Go scan target selectable, defaulting to go.list, with go.sum available for projects wanting like-for-like parity with their legacy Jenkins job.

Considerations

1. go list -compiled -deps requires the project to typecheck, whereas parsing go.sum does not. Combined with continue-on-error from build_permit_fail, a failed go list leaves go.list missing or empty, the scan targets it anyway, and we hit the docs/BRIEF.md D12 hazard — a green scan that evaluated nothing.

   Regardless of which target is chosen, assert the scan target exists and is non-empty before handing it to the scan action, and fail loudly if not, independent of build_permit_fail.

2. It narrows the result set. go.sum carries the whole module graph including test-only and unused modules; go list -deps carries only what compiles in. More accurate, but strictly fewer findings than the legacy job produced. Worth stating explicitly rather than discovering during cutover. A -test variant exists if test-only dependencies are wanted.

3. go mod tidy becomes unnecessary in go.list mode. PR Feat: Add a Go build_type to the Sonatype Lifecycle lane #38 justifies tidy over download on the grounds that a drifting go.sum should fail the scan — sound while go.sum is the target, but with no force once nothing reads it. Sonatype lists go mod tidy only under "Using go.sum for analysis". Consider scoping the step to the go.sum path so it cannot fail for no benefit.

4. Implementation detail: the documented go list invocation is a multi-line Go template. Write it via a quoted heredoc rather than inlining it in YAML. The docs' -test example contains a typo ({{with.Module}}, missing a space) and should not be copy-pasted verbatim.

5. Keep targeting the file, not the directory. If both go.list and go.sum are present, a directory scan would double-count.

Counter-argument to weigh

Defaulting to go.list means a migrated job produces materially different results from the Jenkins job it replaces, muddying before/after comparison during ONAP cutover. If a clean parity check matters, shipping go.sum as the default and flipping later is legitimate. This repository is pre-1.0, which argues for taking the better default now and leaving parity one input away — but the call belongs to whoever owns the ONAP migration.

Related: PR #38.

[ModeSevenIndustrialSolutions]

Status update from PR #38 (head cc52d5e).

The PR now records the vendor-guidance shift in docs/BRIEF.md D20 (dated, with the Go Application Analysis citation) but deliberately keeps go.sum as the sole cli-mode target, deferring the switch here. Agreed on the PR that this is the right split.

Direction agreed in the PR discussion (thread):

1. Migration first, parity preserved: policy-opa-pdp's caller should explicitly pin the mode/target matching its Jenkins-era results, so the cutover comparison is clean and the goalposts do not move for the project team.
2. Then flip the default to go.list in a follow-up PR — this issue.

Two implementation notes settled since this issue was filed:

• Input shape: the PR adopted orthogonal inputs (scan_mode for transport), so the target selector here should follow as go_scan_target: 'list' | 'sum'. The PR intentionally did not pre-add that input with no behaviour behind it; it lands with this change so input and effect ship together.
• Guard placement: cc52d5e moved the non-empty assertion next to the step that produces each scan target (go.sum after tidy, bom.xml after generation), with continue-on-error removed from all three Go steps. The go.list path should follow the same pattern — generate, then assert non-empty, no continue-on-error — and per the PR discussion, go mod tidy should be scoped away from the list path at the same time, since nothing there reads go.sum.

[ModeSevenIndustrialSolutions]

Point 1 is already satisfied

The issue asks, "regardless of which target is chosen, assert the scan target exists and is non-empty before handing it to the scan action, and fail loudly if not, independent of build_permit_fail."

The merged Go path does this:

      - name: 'Go mod tidy'
        if: inputs.build_type == 'go'
        shell: bash
        working-directory: ${{ inputs.path_prefix }}
        run: |
          go mod tidy
          # A tidy go.sum can still be empty for a dependency-free
          # module; scanning that silently would look identical to a
          # broken resolution, so fail loudly instead either way.
          if [ ! -s go.sum ]; then
            echo "::error::go.sum is empty after 'go mod tidy'"
            exit 1
          fi

No continue-on-error, so build_permit_fail cannot soften it — deliberately, per D20. The SBOM path carries the equivalent guard on bom.xml. The D12 hazard the issue flags is closed for the current target.

If go.list is adopted, the same guard needs extending to it, and that matters more there: go list -compiled -deps requires the project to typecheck, so it has a failure mode go.sum parsing does not.

Points 2–5 remain open

The default choice, the narrowing of the result set, scoping go mod tidy to the go.sum path, and the heredoc detail are all untouched. So is the counter-argument about muddying the ONAP cutover comparison — and related to that, #50 and #73 now record the migration guidance that policy-opa-pdp's caller should pin scan_mode explicitly, which is the same "do not move the goalposts mid-cutover" concern in a different input.

Worth striking point 1 from the issue body so whoever picks this up does not re-implement a guard that exists.

Checked against main at 6ee0886, August 2026.