🐛 (go/v2) fix issue introduced by removing the GO111MODULE=on from Dockerfile #2678
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…e the GO111MODULE=on
k8s-ci-robot
added
cncf-cla: yes
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: camilamacedo86 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 |
k8s-ci-robot
added
the
approved
camilamacedo86
changed the title
|
/lgtm Do we have a plan to drop support for "old stuff" 😉 |
k8s-ci-robot
added
the
lgtm
camilamacedo86
pushed a commit
to camilamacedo86/operator-sdk
that referenced
this pull request
May 29, 2022
Signed-off-by: Camila Macedo <cmacedo@redhat.com> - For Golang/Ansible/Helm language-based operators (go/v3, ansible/v1 and helm/v1): applying restrictive SCC for all containers scaffolded by the tool (`k8s versions < 1.19 will no longer work with`). ([More info](kubernetes-sigs/kubebuilder#2700)) - For Golang-based language (go/v2) fix the issue introduced by removing the GO111MODULE=on from Dockerfile. ([More info](kubernetes-sigs/kubebuilder#2678)) - For Golang/Ansible/Helm language-based operators (go/v3, ansible/v1 and helm/v1 language (go/v3), add a new comment with the option `leaderElectionReleaseOnCancel` ((More info)[kubernetes-sigs/kubebuilder#2596]) Only to get the changes from what we currently use in SDK from kubebuilder. - Ensure that scaffolds begin to be performed with a restrive Security Context - Be able to do specific follow up PR so we can discuss properly how we will consume the new additions on Kubebuilder - Make eaiser the process to keep SDK updated, otherwise, it is hard to properly review if we wait to do a big PR with all. - Ensure that SDK features can work with the latest changes performed in Kubebuilder **Extra info** You can check the latest changes on Kubebuilder by looking: kubernetes-sigs/kubebuilder@v3.4.1...master Note that SDK users Kubebuilder as a LIB. So that all that is currently important is updated by default when we bump. However, all that was added to Kubebuilder but still not imported/used in SDK will not be added here. Therefore we can do follow up PRs to get the additions. Why? we have significant changes and additions for example adding the support for the phase 2 plugin, but if we try to do it all in the same PR it will be very hard to get properly reviewed.
camilamacedo86
pushed a commit
to camilamacedo86/operator-sdk
that referenced
this pull request
May 29, 2022
Signed-off-by: Camila Macedo <cmacedo@redhat.com> - For Golang/Ansible/Helm language-based operators (go/v3, ansible/v1 and helm/v1): applying restrictive SCC for all containers scaffolded by the tool (`k8s versions < 1.19 will no longer work with`). ([More info](kubernetes-sigs/kubebuilder#2700)) - For Golang-based language (go/v2) fix the issue introduced by removing the GO111MODULE=on from Dockerfile. ([More info](kubernetes-sigs/kubebuilder#2678)) - For Golang/Ansible/Helm language-based operators (go/v3, ansible/v1 and helm/v1 language (go/v3), add a new comment with the option `leaderElectionReleaseOnCancel` ((More info)[kubernetes-sigs/kubebuilder#2596]) Only to get the changes from what we currently use in SDK from kubebuilder. - Ensure that scaffolds begin to be performed with a restrive Security Context - Be able to do specific follow up PR so we can discuss properly how we will consume the new additions on Kubebuilder - Make eaiser the process to keep SDK updated, otherwise, it is hard to properly review if we wait to do a big PR with all. - Ensure that SDK features can work with the latest changes performed in Kubebuilder **Extra info** You can check the latest changes on Kubebuilder by looking: kubernetes-sigs/kubebuilder@v3.4.1...master Note that SDK users Kubebuilder as a LIB. So that all that is currently important is updated by default when we bump. However, all that was added to Kubebuilder but still not imported/used in SDK will not be added here. Therefore we can do follow up PRs to get the additions. Why? we have significant changes and additions for example adding the support for the phase 2 plugin, but if we try to do it all in the same PR it will be very hard to get properly reviewed.
camilamacedo86
pushed a commit
to camilamacedo86/operator-sdk
that referenced
this pull request
May 29, 2022
Signed-off-by: Camila Macedo <cmacedo@redhat.com> - For Golang/Ansible/Helm language-based operators (go/v3, ansible/v1 and helm/v1): applying restrictive SCC for all containers scaffolded by the tool (`k8s versions < 1.19 will no longer work with`). ([More info](kubernetes-sigs/kubebuilder#2700)) - For Golang-based language (go/v2) fix the issue introduced by removing the GO111MODULE=on from Dockerfile. ([More info](kubernetes-sigs/kubebuilder#2678)) - For Golang/Ansible/Helm language-based operators (go/v3, ansible/v1 and helm/v1 language (go/v3), add a new comment with the option `leaderElectionReleaseOnCancel` ((More info)[kubernetes-sigs/kubebuilder#2596]) Only to get the changes from what we currently use in SDK from kubebuilder. - Ensure that scaffolds begin to be performed with a restrive Security Context - Be able to do specific follow up PR so we can discuss properly how we will consume the new additions on Kubebuilder - Make eaiser the process to keep SDK updated, otherwise, it is hard to properly review if we wait to do a big PR with all. - Ensure that SDK features can work with the latest changes performed in Kubebuilder **Extra info** You can check the latest changes on Kubebuilder by looking: kubernetes-sigs/kubebuilder@v3.4.1...master Note that SDK users Kubebuilder as a LIB. So that all that is currently important is updated by default when we bump. However, all that was added to Kubebuilder but still not imported/used in SDK will not be added here. Therefore we can do follow up PRs to get the additions. Why? we have significant changes and additions for example adding the support for the phase 2 plugin, but if we try to do it all in the same PR it will be very hard to get properly reviewed.
camilamacedo86
pushed a commit
to camilamacedo86/operator-sdk
that referenced
this pull request
Jun 7, 2022
Signed-off-by: Camila Macedo <cmacedo@redhat.com> - For Golang/Ansible/Helm language-based operators (go/v3, ansible/v1 and helm/v1): applying restrictive SCC for all containers scaffolded by the tool (`k8s versions < 1.19 will no longer work with`). ([More info](kubernetes-sigs/kubebuilder#2700)) - For Golang-based language (go/v2) fix the issue introduced by removing the GO111MODULE=on from Dockerfile. ([More info](kubernetes-sigs/kubebuilder#2678)) - For Golang/Ansible/Helm language-based operators (go/v3, ansible/v1 and helm/v1 language (go/v3), add a new comment with the option `leaderElectionReleaseOnCancel` ((More info)[kubernetes-sigs/kubebuilder#2596]) Only to get the changes from what we currently use in SDK from kubebuilder. - Ensure that scaffolds begin to be performed with a restrive Security Context - Be able to do specific follow up PR so we can discuss properly how we will consume the new additions on Kubebuilder - Make eaiser the process to keep SDK updated, otherwise, it is hard to properly review if we wait to do a big PR with all. - Ensure that SDK features can work with the latest changes performed in Kubebuilder **Extra info** You can check the latest changes on Kubebuilder by looking: kubernetes-sigs/kubebuilder@v3.4.1...master Note that SDK users Kubebuilder as a LIB. So that all that is currently important is updated by default when we bump. However, all that was added to Kubebuilder but still not imported/used in SDK will not be added here. Therefore we can do follow up PRs to get the additions. Why? we have significant changes and additions for example adding the support for the phase 2 plugin, but if we try to do it all in the same PR it will be very hard to get properly reviewed.
camilamacedo86
pushed a commit
to camilamacedo86/operator-sdk
that referenced
this pull request
Jun 8, 2022
Signed-off-by: Camila Macedo <cmacedo@redhat.com> - For Golang/Ansible/Helm language-based operators (go/v3, ansible/v1 and helm/v1): applying restrictive SCC for all containers scaffolded by the tool (k8s versions < 1.19 will no longer work with). - For Golang-based language (go/v2) fix the issue introduced by removing the GO111MODULE=on from Dockerfile. ([More info](kubernetes-sigs/kubebuilder#2678)) - For Golang/Ansible/Helm language-based operators (go/v3, ansible/v1 and helm/v1 language (go/v3), add a new comment with the option `leaderElectionReleaseOnCancel` ((More info)[kubernetes-sigs/kubebuilder#2596]) Only to get the changes from what we currently use in SDK from kubebuilder. - Ensure that scaffolds begin to be performed with a restrive Security Context - Be able to do specific follow up PR so we can discuss properly how we will consume the new additions on Kubebuilder - Make eaiser the process to keep SDK updated, otherwise, it is hard to properly review if we wait to do a big PR with all. - Ensure that SDK features can work with the latest changes performed in Kubebuilder **Extra info** You can check the latest changes on Kubebuilder by looking: kubernetes-sigs/kubebuilder@v3.4.1...master Note that SDK users Kubebuilder as a LIB. So that all that is currently important is updated by default when we bump. However, all that was added to Kubebuilder but still not imported/used in SDK will not be added here. Therefore we can do follow up PRs to get the additions. Why? we have significant changes and additions for example adding the support for the phase 2 plugin, but if we try to do it all in the same PR it will be very hard to get properly reviewed. Co-authored-by: Varsha <varshaprasad96@gmail.com>
camilamacedo86
pushed a commit
to camilamacedo86/operator-sdk
that referenced
this pull request
Jun 8, 2022
Signed-off-by: Camila Macedo <cmacedo@redhat.com> - For Golang/Ansible/Helm language-based operators (go/v3, ansible/v1 and helm/v1): applying restrictive SCC for all containers scaffolded by the tool (k8s versions < 1.19 will no longer work with). - For Golang-based language (go/v2) fix the issue introduced by removing the GO111MODULE=on from Dockerfile. ([More info](kubernetes-sigs/kubebuilder#2678)) - For Golang/Ansible/Helm language-based operators (go/v3, ansible/v1 and helm/v1 language (go/v3), add a new comment with the option `leaderElectionReleaseOnCancel` ((More info)[kubernetes-sigs/kubebuilder#2596]) Only to get the changes from what we currently use in SDK from kubebuilder. - Ensure that scaffolds begin to be performed with a restrive Security Context - Be able to do specific follow up PR so we can discuss properly how we will consume the new additions on Kubebuilder - Make eaiser the process to keep SDK updated, otherwise, it is hard to properly review if we wait to do a big PR with all. - Ensure that SDK features can work with the latest changes performed in Kubebuilder **Extra info** You can check the latest changes on Kubebuilder by looking: kubernetes-sigs/kubebuilder@v3.4.1...master Note that SDK users Kubebuilder as a LIB. So that all that is currently important is updated by default when we bump. However, all that was added to Kubebuilder but still not imported/used in SDK will not be added here. Therefore we can do follow up PRs to get the additions. Why? we have significant changes and additions for example adding the support for the phase 2 plugin, but if we try to do it all in the same PR it will be very hard to get properly reviewed. Co-authored-by: Varsha <varshaprasad96@gmail.com>
camilamacedo86
added a commit
to operator-framework/operator-sdk
that referenced
this pull request
Jun 8, 2022
* Upgrade Kubebuilder dep from 3.4.1 to the commit 800fdeec6e5c Signed-off-by: Camila Macedo <cmacedo@redhat.com> - For Golang/Ansible/Helm language-based operators (go/v3, ansible/v1 and helm/v1): applying restrictive SCC for all containers scaffolded by the tool (k8s versions < 1.19 will no longer work with). - For Golang-based language (go/v2) fix the issue introduced by removing the GO111MODULE=on from Dockerfile. ([More info](kubernetes-sigs/kubebuilder#2678)) - For Golang/Ansible/Helm language-based operators (go/v3, ansible/v1 and helm/v1 language (go/v3), add a new comment with the option `leaderElectionReleaseOnCancel` ((More info)[kubernetes-sigs/kubebuilder#2596]) Only to get the changes from what we currently use in SDK from kubebuilder. - Ensure that scaffolds begin to be performed with a restrive Security Context - Be able to do specific follow up PR so we can discuss properly how we will consume the new additions on Kubebuilder - Make eaiser the process to keep SDK updated, otherwise, it is hard to properly review if we wait to do a big PR with all. - Ensure that SDK features can work with the latest changes performed in Kubebuilder **Extra info** You can check the latest changes on Kubebuilder by looking: kubernetes-sigs/kubebuilder@v3.4.1...master Note that SDK users Kubebuilder as a LIB. So that all that is currently important is updated by default when we bump. However, all that was added to Kubebuilder but still not imported/used in SDK will not be added here. Therefore we can do follow up PRs to get the additions. Why? we have significant changes and additions for example adding the support for the phase 2 plugin, but if we try to do it all in the same PR it will be very hard to get properly reviewed. Co-authored-by: Varsha <varshaprasad96@gmail.com> * trying to fix ansible lint Co-authored-by: Varsha <varshaprasad96@gmail.com>
VenkatRamaraju
pushed a commit
to VenkatRamaraju/operator-sdk
that referenced
this pull request
Jun 9, 2022
…or-framework#5814) * Upgrade Kubebuilder dep from 3.4.1 to the commit 800fdeec6e5c Signed-off-by: Camila Macedo <cmacedo@redhat.com> - For Golang/Ansible/Helm language-based operators (go/v3, ansible/v1 and helm/v1): applying restrictive SCC for all containers scaffolded by the tool (k8s versions < 1.19 will no longer work with). - For Golang-based language (go/v2) fix the issue introduced by removing the GO111MODULE=on from Dockerfile. ([More info](kubernetes-sigs/kubebuilder#2678)) - For Golang/Ansible/Helm language-based operators (go/v3, ansible/v1 and helm/v1 language (go/v3), add a new comment with the option `leaderElectionReleaseOnCancel` ((More info)[kubernetes-sigs/kubebuilder#2596]) Only to get the changes from what we currently use in SDK from kubebuilder. - Ensure that scaffolds begin to be performed with a restrive Security Context - Be able to do specific follow up PR so we can discuss properly how we will consume the new additions on Kubebuilder - Make eaiser the process to keep SDK updated, otherwise, it is hard to properly review if we wait to do a big PR with all. - Ensure that SDK features can work with the latest changes performed in Kubebuilder **Extra info** You can check the latest changes on Kubebuilder by looking: kubernetes-sigs/kubebuilder@v3.4.1...master Note that SDK users Kubebuilder as a LIB. So that all that is currently important is updated by default when we bump. However, all that was added to Kubebuilder but still not imported/used in SDK will not be added here. Therefore we can do follow up PRs to get the additions. Why? we have significant changes and additions for example adding the support for the phase 2 plugin, but if we try to do it all in the same PR it will be very hard to get properly reviewed. Co-authored-by: Varsha <varshaprasad96@gmail.com> * trying to fix ansible lint Co-authored-by: Varsha <varshaprasad96@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
The
GO111MODULE=onwas removed from go/v2 with the PR: #2507However, projects scaffolds with go/v2 are using golang 1.13 which requires this option