-
Notifications
You must be signed in to change notification settings - Fork 289
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
Update Go, Kubernetes and other dependencies #582
Conversation
@@ -303,7 +302,7 @@ func InitResourceMap(conf *config.Config) { | |||
AllowedKubectlVerbMap[r] = true | |||
} | |||
|
|||
resourceList, err := DiscoveryClient.ServerResources() | |||
_, resourceList, err := DiscoveryClient.ServerGroupsAndResources() |
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.
ServerResources
was deprecated and removed in 1.24. For example, see comment from 1.22:
https://github.com/kubernetes/client-go/blob/v0.22.7/discovery/discovery_client.go#L98
@@ -212,7 +212,6 @@ func GetObjectMetaData(obj interface{}) metaV1.ObjectMeta { | |||
Annotations: unstructuredObject.GetAnnotations(), | |||
OwnerReferences: unstructuredObject.GetOwnerReferences(), | |||
Finalizers: unstructuredObject.GetFinalizers(), | |||
ClusterName: unstructuredObject.GetClusterName(), |
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.
https://kubernetes.io/docs/reference/kubernetes-api/common-definitions/object-meta/#Ignored
Deprecated: ClusterName is a legacy field that was always cleared by the system and never used; it will be removed completely in 1.25.
Hi @PrasadG193, This is a base for #581 and also I will use it to prepare other PRs with improvements 🙂 Thanks a lot! EDIT: I also rebased the pull request 🙂 |
2ef85a0
to
a988ea9
Compare
pkg/events/events.go
Outdated
@@ -124,7 +124,7 @@ func New(object interface{}, eventType config.EventType, resource, clusterName s | |||
event.Action = eventObj.Action | |||
event.TimeStamp = eventObj.LastTimestamp.Time | |||
// Compatible with events.k8s.io/v1 | |||
if eventObj.LastTimestamp.IsZero() { | |||
if eventObj.LastTimestamp.IsZero() && eventObj.Series != nil { |
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.
Hey @pkosiec, |
Hi @PrasadG193, which part of this pull request do you consider as a breaking change? Do you mean the Kubernetes-related dependencies (like client-go)? Between K8s 1.20 and 1.24 there were the following breaking changes in deprecated APIs: https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22. As you can see, all the removed APIs have been deprecated since Kubernetes 1.8-1.19. So there shouldn't be any problems, and to avoid technical debt, it would be great to have the dependencies constantly updated. When it comes to the integration-related dependencies (Discord, Slack, etc.) I bumped them to the latest minor versions, so don't worry, they shouldn't have any breaking changes if they all do proper SemVer tagging (from what I saw, they do). That said, I think it would be great to do alpha/beta release before releasing a stable version and give time to the real users to report any issues they face. And when it comes to 0.13 release, could you please hold off before releasing a new version? Along with @mszostok, we want to contribute quite a lot of features (see our GitHub Project we prepared: https://github.com/infracloudio/botkube/projects/10). So we were thinking about having feature-packed 0.13 to show the community this cool project lives on, and the development didn't stop 🚀 The Slack multichannel support could be a release theme, and the first alpha version could be released within a month. But, before we contribute such changes, we need to make sure there's no technical debt to be fully productive with implementing new features. What do you think? Cheers! 🙂 |
a988ea9
to
d3266ec
Compare
PR rebased to the latest |
As far as I know, @mszostok will be AFK until tomorrow, but of course let's wait for his opinion 🙂 I think it would make sense to deliver Lark support along with other features, as, as you said, the Lark documentation is still in progres. In a result there will be more time to finalize the documentation without blocking some other features from merging 🙂 Later we could switch from git flow to GitHub flow and have dedicated release branches, to make sure we can support multiple versions. @PrasadG193 Anyway, apart from the release, does my explanation around dependencies bump / breaking changes make sense? Is it OK for you to have this PR merged soon, regardless which features 0.13 will bring? Thanks! 🙂 |
Cool, sounds good to me. 🙂 |
d3266ec
to
7902189
Compare
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.
LGTM
##### ISSUE TYPE - Bug fix Pull Request ##### SUMMARY - Do not log full Slack event details in case of unmarshalling error This is an issue of the upstream library. While I prepared a workaround, I also prepared a simple change in `slack-go/slack` repo: slack-go/slack#1067 **NOTE:** This pull request depends on #582. Please merge #582 first, and I will rebase this one. Actual changes on this PR: 7813821 Fixes #579 ##### TESTING See the original issue for testing instruction: #579 You can use `pkosiec/botkube:slack-unmarshall-err` Docker image for testing the workaround. Once you run my image and try to reproduce the issue, you'll see in the logs: ``` ERRO[2022-05-19T16:00:57Z] Slack unmarshalling error: RTM Error: Received unmapped event "user_huddle_changed" ERRO[2022-05-19T16:00:57Z] Slack unmarshalling error: RTM Error: Received unmapped event "sh_room_join" ERRO[2022-05-19T16:01:00Z] Slack unmarshalling error: RTM Error: Received unmapped event "sh_room_leave" ```
##### ISSUE TYPE - Feature Pull Request ##### SUMMARY Add an option to push the BotKube image automatically on PR. It's alternative approach for #604. This PR will solve the problem with manual PR builds, e.g. we had that issue here: - #601 - #593 - #582 - #583 Example run: https://github.com/mszostok/botkube/runs/6714112689?check_suite_focus=true Fixes #590 To ensure that secrets won't be available for untrusted code, first we need to build the image and share it with the second job, which doesn't check out the untrusted code and can safely push an artifact to ghcr.io. The flow is as follows: ``` Job1: image build -> image save -> artifact upload Job2: artifact download -> image load -> image push ``` Job1—runs untrusted code but without write repo perms Job2—push built image with package write perms #### Security This article describes it well: https://securitylab.github.com/research/github-actions-preventing-pwn-requests/
ISSUE TYPE
SUMMARY
github.com/slack-go/slack
(community-maintained fork ofnlopes/slack
) instead ofnlopes/slack
Fix panic when a singleton Event is receivedResolves #587
TESTING
I've already tested Slack, Mattermost, and Discord. Unfortunately, I couldn't test other integrations, but for the others I bumped them just to the latest minor versions (to not take any breaking changes).
You can use my Docker image
pkosiec/botkube:update-deps
which I've built with the following commands: