origin-release: add golang-1.14#8542
Conversation
Signed-off-by: Steve Kuznetsov <skuznets@redhat.com>
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: stevekuznetsov The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci-robot
added
the
approved
| # | ||
| # The standard name for this image is openshift/origin-release | ||
| # | ||
| FROM centos:7 |
There was a problem hiding this comment.
Maybe we can start using 8 for new stuff?
| triggers: | ||
| - imageChange: {} | ||
| type: ImageChange | ||
| - apiVersion: v1 |
There was a problem hiding this comment.
Out of curiosity, what triggers this when a now golang patch version becomes available?
| GOARM=5 \ | ||
| GOPATH=/go \ | ||
| GOROOT=/usr/local/go \ | ||
| GOFLAGS='-mod=vendor' \ |
There was a problem hiding this comment.
From the Go 1.14 Release Notes:
Go command
Vendoring
When the main module contains a top-level vendor directory and its go.mod file specifies go 1.14 or higher, the go command now defaults to -mod=vendor for operations that accept that flag. A new value for that flag, -mod=mod, causes the go command to instead load modules from the module cache (as when no vendor directory is present).
When -mod=vendor is set (explicitly or by default), the go command now verifies that the main module's vendor/modules.txt file is consistent with its go.mod file.
@stevekuznetsov given the above, I wonder if it would be a good idea to leave this flag out? Without it, Go should now "do the correct thing" depending on whether the project being built vendors dependencies or not.
There was a problem hiding this comment.
@grdryn no it does not unless you bump the go.mod:
and its go.mod file specifies go 1.14 or higher
There was a problem hiding this comment.
@alvaroaleman yes, that's true; although I'd assume that projects would update the go.mod to specify that if they were going to use this image. I guess there's no guarantee of that though.
|
Anything blocking a merge of this currently? Serverless/Knative stuff is currently broken due to not being able to build with go1.14 😢 |
|
@stevekuznetsov we are also blocked on one PR waiting for this change, just friendly bump :) |
|
@markusthoemmes: Closed this PR. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
8 participants
Signed-off-by: Steve Kuznetsov skuznets@redhat.com
/assign @smarterclayton