🐛 remove setup-go requirement for Packaging with goreleaser

[AdamKorcz]

What kind of change does this PR introduce?

(Is it a bug fix, feature, docs update, something else?)

• PR title follows the guidelines defined in our pull request documentation

What is the current behavior?

Currently, the Go JobMatcher requires both the setup-go and goreleaser actions to be used to consider the project to use and automated releaser. Some users have adopted other actions that install Go and still use the goreleaser action in which case Scorecard will not see the goreleaser action.

What is the new behavior (if this is a feature change)?**

This PR removes the requirement that users must use the setup-go action to Scorecard recognizing goreleaser.

• Tests for the changes have been added (for bug fixes/features)

Which issue(s) this PR fixes

Fixes #4617

Special notes for your reviewer

Does this PR introduce a user-facing change?

For user-facing changes, please add a concise, human-readable release note to
the release-note

(In particular, describe what changes users might need to make in their
application as a result of this pull request.)

Fix bug in parsing workflow files.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 68.30%. Comparing base (353ed60) to head (1ebe5b6).
Report is 193 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4673      +/-   ##
==========================================
+ Coverage   66.80%   68.30%   +1.49%     
==========================================
  Files         230      249      +19     
  Lines       16602    18895    +2293     
==========================================
+ Hits        11091    12906    +1815     
- Misses       4808     5130     +322     
- Partials      703      859     +156     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[spencerschrock]

Currently, matches will return false if the first Step of the JobMatcher fails. This is a problem if there are multiple steps in the JobMatcher where the second one should return true.

This is by design, the matcher is looking for every step in the pattern to be in the job. "Each step in this field has a matching step in the job"

scorecard/checks/fileparser/github_workflow.go

Lines 328 to 333 in 42e0ac2

	// JobMatcher is rule for matching a job.
	type JobMatcher struct {
	// The text to be logged when a job match is found.
	LogText string
	// Each step in this field has a matching step in the job.
	Steps []*JobMatcherStep

As written, this PR would give credit to any repo which uses actions/setup-go regardless of if it uses goreleaser. e.g.
https://github.com/spencerschrock/actions-test/blob/f4f716a8b0df876e28868d879246863b2c4bcfa8/.github/workflows/disk.yml#L12

  "score": 10.0,
  "checks": [
    {
      "details": [
        "Info: Project packages its releases by way of GitHub Actions.: .github/workflows/disk.yml:8"
      ],
      "score": 10,
      "reason": "packaging workflow detected",
      "name": "Packaging",

I think the question we want to ask is: do we need actions/setup-go to give credit for a goreleaser release workflow.

scorecard/checks/fileparser/github_workflow.go

Lines 557 to 565 in 42e0ac2

	// Go packages.
	Steps: []*JobMatcherStep{
	{
	Uses: "actions/setup-go",
	},
	{
	Uses: "goreleaser/goreleaser-action",
	},
	},

[AdamKorcz]

Thanks @spencerschrock Essentially this means that we (in this case) only detect a goreleaser use if it is preceded by a step using actions/setup-go. Do you know what the logic behind this is? As in, why do we only want to detect goreleaser if it is preceded by setup-go?

[spencerschrock]

only detect a goreleaser use if it is preceded by a step using actions/setup-go

as long as all steps are present, I don't think order matters to our current implementation.

Do you know what the logic behind this is?

This predates my time on the project. Detection for Go was first added in #800, but similar logic (expecting language setup) was added in #132 for npm and Python.

My guess is it was to cut down on false positives, as the entire workflow file was scanned with a regex, instead of the workflow parsing and step analysis that happens now.

[AdamKorcz]

okay, it may be better to remove actions/setup-go from the JobMatcher Uses. It seems unnecessary that both actions need to exist for the goreleaser action to be valid.

[spencerschrock]

okay, it may be better to remove actions/setup-go from the JobMatcher Uses. It seems unnecessary that both actions need to exist for the goreleaser action to be valid.

Seems reasonable to me.

[AdamKorcz]

Updated the PR and the PR description.

[spencerschrock]

/scdiff generate Packaging,Token-Permissions

[github-actions]

Here's a link to the scdiff run