-
Notifications
You must be signed in to change notification settings - Fork 84
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
[GH-15] manage webhooks with slash commands #137
[GH-15] manage webhooks with slash commands #137
Conversation
Codecov Report
@@ Coverage Diff @@
## master #137 +/- ##
==========================================
+ Coverage 39.79% 42.31% +2.51%
==========================================
Files 16 16
Lines 1495 1633 +138
==========================================
+ Hits 595 691 +96
- Misses 840 871 +31
- Partials 60 71 +11
Continue to review full report at Codecov.
|
I've made all the required upstream changes, and it was just released today https://github.com/xanzy/go-gitlab/releases/tag/v0.30.0 a little more work on my end and this should be ready to move forward. |
Added user message based on Web hook status when /gitlab subscribe is used. (#130) Message alerting the user to the need to add a webhook is functioning. Additional refactoring and tests needed. single webhook test with mocking refactored project hook tests added no webhooks test moved mock function to gitlabtest package replaced manual mocks with auto generated refactored plugin command handling and clarified messages added api error test removed mocks that are no longer needed removed test for GetProjectHooks as it seems to implementation-specific go format removed shadow declaration based on vet output broke out subscribeComand method to improve testability tested no subscripions paramaterized testSubscribeCommand tests mocked KVSet tests webhook found moved tests out of plugin_test and into command_test fixed linting issues fixed Error identifier Co-Authored-By: Michael Kochell <mjkochell@gmail.com> fixed Error identifier Co-Authored-By: Michael Kochell <mjkochell@gmail.com> spelling Co-Authored-By: Michael Kochell <mjkochell@gmail.com> generated mock with gomock works for all test except no Substitutions all tests pass changed mock boolean flag name WIP
new webhook test hard coded wip added trigger default logic creates webhook with nice output formated project hooks properly explicit trigers works with explicit URL wip improved hook formating
tested add group hook abstracted group and project hook options updated subscribe messages fixed spelling rebased with upsream master
feature complete, @hanzei Work in Progress can be removed. |
go mod tidy merged go.sum conlict go tidy
@ericjaystevens Heads up that there is a merge conflict to resolve |
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.
Looks good to me! Thanks for the contribution @ericjaystevens, great work!
One question below.
fullPath := strings.Split(namespace, "/") | ||
|
||
siteURL := *p.API.GetConfig().ServiceSettings.SiteURL | ||
urlPath := fmt.Sprintf("%v/%s", siteURL, inboundWebhookURL) |
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.
Shouldn't we add the port as well in case it is not :80
?
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.
Good Thinking, I use port 8065 in my test environment. But I have the port number included in my site URL.
Looking at the System Console under site URL I see,
The URL that users will use to access Mattermost. Standard ports, such as 80 and 443, can be omitted, but non-standard ports are required. For example: http://example.com:8065. This setting is required.
So I think it might be safe to assume the port will be included in the Site URL. But if that's not a safe assumption, it should be an easy check.
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.
You are absolutely right. One case worth checking might be siteURL
being empty, because it's a default. I'd suggest using
"localhost" + *p.API.GetConfig().ServiceSettings.ListenAddress
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 it's a good idea to check siteURL for empty, I'll add that.
I'm pretty sure other things won't work (like subscribe and activate) if siteURL is not set. But if gets unset webhook creation would set webhooks to point to just the inboundWebhookURL, which would be unexpected.
I'm not sure computing the URL is practical or desired, they could be behind a load balancer or proxy and we wouldn't know their external IP/FQDN.
How about I just add a check, and if it is empty I fail the webhook creation with a message like
Unable to create webhook. The Mattermot Site URL is not set. Set it in the admin console or rerun
/gitlab webhook add group/project URL
including the desired URL.
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.
Thanks @ericjaystevens, looks good to me!
/update-branch |
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.
Awesome work 🎉
I leaved a few suggestions
* PipelineEvents | ||
* WikiPageEvents | ||
* SSLverification | ||
* |url| is the URL that will be called when triggered. Defaults to this plugins URL |
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.
What is a use case for setting this not to the plugin URL?
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.
creating a webhook for your CI/CD tooling or another chat or notification service
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 you elaborate a bit? Is the exact use case that a user wan't to create a webhook to an different service inside of Mattermost?
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.
Yes, An example user story would be a developer creates a new GitLab repo, and wants to get it added to the team's Jenkins server. So the developer messages the Jenkins administrator to get the token and Jenkins URL for the webhook. Then the developer runs the Mattermost Gitlab Plugin command and creates the webhook to Jenkins.
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.
Great work 🎉
use ! instead of == false Co-authored-by: Ben Schumacher <ben.schumacher@mattermost.com>
@iomodo Do you have a local GitLab instance setup to test these changes? |
@hanzei it's on my todo list. |
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.
Started testing this PR on a local instance. Found a bug I missed in the review.
server/gitlab/gitlab.go
Outdated
client := internGitlab.NewOAuthClient(tc, token.AccessToken) | ||
if err := client.SetBaseURL(g.enterpriseBaseURL); err != nil { | ||
return nil, fmt.Errorf("can't set base url to GitLab client lib: %w", err) | ||
client, err := internGitlab.NewOAuthClient(token.AccessToken) |
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.
Not setting base url will make requests go to the default gitlab.com
URL.
What was the reason for changing gitlabConnect
method?
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.
You are absolutely right. The reason for the modifications to gitlabConnect
was because of changes in go-gitlab. The types of arguments for NewOAuthClient
changed, and SetBaseURL
became a private function. I must have changed it to get this feature to compile and the forgot that the gitlabConnect
method needs a re-write.
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 just pushed a change and tested it with Gitlab.com. Here is the link to the breaking change commit that I updated gitlabConnect to address. xanzy/go-gitlab#826
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.
Tested locally, works as expected. Could not test groups
though.
Great job @ericjaystevens !
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.
Thanks for testing @iomodo. I have added this to release testing so it is included in end to end testing in the next release.
LGTM!
Huge thanks @ericjaystevens for this contribution.
Looks like https://mattermost.gitbook.io/plugin-gitlab/setup/configuration needs to be updated following this change. |
@ericjaystevens Would you be open on updating the documentation? |
@bbodenmiller Thanks for the hint 👍 |
Summary
Add features to manage projects and group scoped GitLab webhooks.
When a user subscribes to a new project or group, it will tell them the command to run to create a webhook, if one isn't already created for the group/project.
TODO
Ticket Link
fixes #15
fixes #156