🌱 Allow override of go-verdiff result via label

[tmshort]

Rather than disabling the go-verdiff CI to allow it to pass when there is a legitimate golang version change, use a label to override the test results.

The label is (override-go-verdiff).

Description

Reviewer Checklist

• API Go Documentation
• Tests: Unit Tests (and E2E Tests, if appropriate)
• Comprehensive Commit Messages
• Links to related GitHub Issue(s)

[netlify]

✅ Deploy Preview for olmv1 ready!

Name	Link
🔨 Latest commit	5c9faa7
🔍 Latest deploy log	https://app.netlify.com/sites/olmv1/deploys/6824a40557aeba00084854e9
😎 Deploy Preview	https://deploy-preview-1964--olmv1.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[tmshort]

/approve

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 66.78%. Comparing base (d873ec1) to head (5c9faa7).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1964   +/-   ##
=======================================
  Coverage   66.78%   66.78%           
=======================================
  Files          75       75           
  Lines        6337     6337           
=======================================
  Hits         4232     4232           
  Misses       1841     1841           
  Partials      264      264           

Flag	Coverage Δ
e2e	45.19% <ø> (ø)
unit	56.38% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[grokspawn]

Why?
We already made this unconditionally executed and required.
Is there a reason we need to provide an override capability as well?

Is the issue here that the golang version went up, not that it threatened to exceed our high-water mark? (in other words, is the check enforcing the wrong thing?)

[tmshort]

Why? We already made this unconditionally executed and required. Is there a reason we need to provide an override capability as well?

Is the issue here that the golang version went up, not that it threatened to exceed our high-water mark? (in other words, is the check enforcing the wrong thing?)

There are times we want to be able to override this check. For example, we can go up to golang 1.23.6 as of right now without any downstreaming challenges. But we can't do that if the test is required and always fails. That would mean making the test non-required, and I'm not sure we want to do that and allow something we don't want to slip through.

But yes, there may be bingo tools and other updates that can be permitted, and we should allow that EXPLICIT override.

[grokspawn]

There are times we want to be able to override this check. For example, we can go up to golang 1.23.6 as of right now without any downstreaming challenges. But we can't do that if the test is required and always fails. That would mean making the test non-required, and I'm not sure we want to do that and allow something we don't want to slip through.

Aside from vendoring challenges, this project is concerned with coordinating the golang version (including bingo'd tools) to not grow. That isn't really the right goal, IMO, since growth under a threshold should not be problematic. It's when this project (and projects which include its packages) advances a version collectively.

So maybe it makes more sense for this to obtain a threshold version, and allow anything which doesn't exceed it. We could follow the pattern of actions/setup-go's go-version-file and still use the underlying concept that the project's root go.mod is the "do not exceed" threshold.

Edit: we use the root go.mod as reference, but I still don't see the value in erroring when any go version changes.

[grokspawn]

I'd delete lines 63-78. The failures we're seeing in the kustomize bump are where the golang version changed but still lies at/below the threshold.
Does it matter if the version changed, if it's below the threshold?

[tmshort]

I'd delete lines 63-78. The failures we're seeing in the kustomize bump are where the golang version changed but still lies at/below the threshold. Does it matter if the version changed, if it's below the threshold?

We already use the root go.mod as the threshold, so we're good there, and yes we ought to be fine if nothing exceeds that.
I'd prefer to keep those lines, and instead put it under a flag option; I'd rather not discard that code.

[grokspawn]

We already use the root go.mod as the threshold, so we're good there, and yes we ought to be fine if nothing exceeds that.
I'd prefer to keep those lines, and instead put it under a flag option; I'd rather not discard that code.

It's not discarded if it was previously committed.
But my point is really that we need the check to keep us from advancing beyond a specific version. If we can use the go.mod in the root here as the sentinel version, fine.
But why would we want to alert if any go version changes in future commits?
IMO, this should be something which is enabled with a flag and not in the common path, if we want to keep it.

[tmshort]

That's what I meant.
Please review the updated code.
However, we need to check if the threshold version has changed, so that's kept as an error, otherwise, it could mask a problem!

[grokspawn]

nit: define GO_VER after ROOT_GO_MOD, and change it to

GO_VER=$(sed -En 's/^go (.*)$/\1/p' ${ROOT_GO_MOD})

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: grokspawn, tmshort

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [grokspawn,tmshort]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment