-
Notifications
You must be signed in to change notification settings - Fork 335
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bump min go version to 1.18 && read build info from embedded binary #2548
Conversation
cc @wlynch |
Codecov Report
@@ Coverage Diff @@
## main #2548 +/- ##
==========================================
- Coverage 81.64% 81.61% -0.03%
==========================================
Files 163 163
Lines 9745 9715 -30
==========================================
- Hits 7956 7929 -27
+ Misses 1551 1549 -2
+ Partials 238 237 -1
Continue to review full report at Codecov.
|
unit tests flaked (metrics) cc @imjasonh for tekton pipeline downstream failure - |
One option is we fail silently if the |
Or if the binaries/images are built with I'll prepare a PR to fix Tekton's usage though, it doesn't look like these tests need to use |
knative/pkg#2548 changes pkg/changeset.Get to read VCS information from information embedded by the Go compiler into built binaries, instead of relying on the convention that a kodata/HEAD symlink exists pointing to the repo's .git/HEAD, and a kodata/refs points to .git/refs. This fails in tests though, since tests don't stamp this information into the binary where it can be read. This change removes our tests' usage of changeset.Get and instead replaces those fake commit SHAs with more obviously placeholder values. It doesn't seem that the tests cared that it was an actual SHA, let along the actual current SHA, they just needed any value that looked like a SHA.
- Use a sync.Once to prevent double parsing - Support SHA256 - Allow non-SHA revision strings
Ok added some tweaks
|
koDataPath := os.Getenv(koDataPathEnvName) | ||
if koDataPath == "" { | ||
return nil, fmt.Errorf("%q does not exist or is empty", koDataPathEnvName) | ||
if shaRegexp.MatchString(revision) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically, we don't need this check 😎
(not necessarily advice to remove it, just a funny coincidence)
Actually, I wonder if this should just be if len(revision) >= 7
, so folks using Subversion or whatever can still enjoy this goodness. I'm not sure there aren't other places we assume Git in and around here, but just in case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'd leave it as - since I don't want to assume truncating will work for different VCS - ie svn is numeric so we'd be alternating the commit id
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A further improvement could be to do this only for vcs that use SHA's for revisions -ie git, hg etc.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dprotaso, imjasonh 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:
Approvers can indicate their approval by writing |
// Get returns the 'vcs.revision' property from the embedded build information | ||
// This function will return an error if value is not a valid Git SHA | ||
// | ||
// The result will have a '-dirty' suffix if the workspace was not clean | ||
func Get() (string, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we have a changeset.MustGet
that panics if it can't detect the version? I'm updating some callsites to get this once at init
-time, and they're all just log.Fatal
ing if this returns an error. Or should this return Unknown
if it can't read build info, and just never return an error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or should this return Unknown if it can't read build info, and just never return an error?
I was thinking about this - let me do it in a follow up
build info (vcs.revision) is now embedded in the go binary with go1.18 see: knative/pkg#2548
build info (vcs.revision) is now embedded in the go binary with go1.18 see: knative/pkg#2548
knative/pkg#2548 changes pkg/changeset.Get to read VCS information from information embedded by the Go compiler into built binaries, instead of relying on the convention that a kodata/HEAD symlink exists pointing to the repo's .git/HEAD, and a kodata/refs points to .git/refs. This fails in tests though, since tests don't stamp this information into the binary where it can be read. This change removes our tests' usage of changeset.Get and instead replaces those fake commit SHAs with more obviously placeholder values. It doesn't seem that the tests cared that it was an actual SHA, let along the actual current SHA, they just needed any value that looked like a SHA.
Fixes: #2427
This should let us drop
HEAD
andrefs
in ourkodata
folders/kind cleanup
Release Note