Add option to not send the "hello!" message to non-whitelisted pull request submissions #276
Conversation
|
So I am working on moving as many things out of the main config/global files as possible. If you can pull this out into an extension, then I will review. Otherwise when I get to the whitelist I will add it. I hope that makes sense. |
|
Can you give me an example of what this kind of extension looks like? I'm not entirely confident with Jenkins internals yet, so a pointer would help |
|
Check out how comments are handled now. jenkinsci#89 I admit, this task will take some work. |
|
I finally have some time to look back into this. To confirm, currently the addComment use which this patch alters is not extension-based at all (and has no extension points), so the prerequisite is to make the existing comment code in GhprbPullRequest.java extension-based, then I can actually modify it? |
|
Actually just save your global config with an empty request for retest phrase, then no comment will be made. |
|
That's not really very useful, since you can't set the request for retest phrase on a per-job basis. Setting it to blank mutes every PR builder on a given Jenkins instance. The point is to be able to mute specific jobs, e.g. if you have 4 different jobs all pointing to the same repo. |
|
I will see if i can get something out today. |
directhex
force-pushed
the
suppress-hello
branch
from
0d3f851 to
5bafc13
Compare
|
(I haven't done the extension-based commenting yet, I just wanted to rebase against current master) |
directhex
force-pushed
the
suppress-hello
branch
from
5bafc13 to
a13c5e7
Compare
|
Can one of the admins verify this patch? |
update 'githubPullRequest' to 'pullRequest' in Job DSL section of README
…mmit message for your changes. Lines starting
Add an option to not have the GHPRB manage its webhooks. This is preferable in cases where we have a lot of projects pointing at the same repo, or when the ghprb account has no admin access to the repo
This change reduces the number of API calls made by the ghprb plugin. .NET CI was hitting rate limits pretty regularly. There are a few major improvements:
* When using webhooks, we do not check comments (pull comment data) except when absolutely necessary. We recieve all the comment info through the hooks, so we only need to check for updated comments when we have a new pull request or when jenkins restarts.
* Never force a GH pull request update when a comment update comes through. If a comment update came through, we're using webhooks and will have gotten the updated PR event.
* initGhRepository isn't necessary when a GhprbRepository is created. It's not used in the pull request trigger init, and causes an API call. It can be called on demand as necessary. This also dramatically improves startup time in Jenkins instances that have a lot of PR triggered jobs
Additional fixes:
* Fixes a case where the pull request data wasn't saved on a GH hash update (which leads to most PRs restarting testing on any comment if Jenkins restarts)
* Fixes a potential race condition where multiple triggers would attempt to set up hooks at the same time.
Not all possible improvements are included. When a new PR or updated PR event is sent to Jenkins, we could pull the GHPullRequest info for affected projects once, instead of for each project which we do today.
-Fixed the bug with inability to change the skip build phrase in a job. It now stores it properly. -Skip build phrase now checks in a pull request title as well as it's body. -Added DSL Support for skip build phrase.
Reduce API calls
Add option to avoid managing of webhooks
Adding functionality to not post commit status for children jobs
Add one-line test output option for upstream status
…multiple downstream jobs
…l-trigger-name Revert "update 'githubPullRequest' to 'pullRequest' in Job DSL section of README"
…l-publisher-name Revert "update 'mergeGithubPullRequest' to 'mergePullRequest' in Job DSL sect…"
This allows for more flexible PR building, since you can say that a PR builds for everything except for specific branches. While this may be able to be done using the current setup and some complicated regular expressions, I think have a clear blacklist is a more ideal implementation.
Merge only works when trigger phrase is present jenkinsci#257
…n-template Add build description template to Job DSL extension
Allow for blacklisting of target branches
Add DS_Store
Since the description and title also make it into the builds as variables, the edited hook should also be a valid trigger to trigger new builds when these pieces of data change. One use-case is validations on the description message to include a proper change log.
Handle "edited" pull-request hooks
|
Can one of the admins verify this patch? |
|
OK, so I'm looking at rewriting this using the extension system which sorta grew into existence while I was slacking off. As I understand it, there's a system in place to allow control over comments as sent, as used here: https://github.com/janinko/ghprb/blob/master/src/main/java/org/jenkinsci/plugins/ghprb/GhprbRepository.java#L205-L225 However, that mechanism is not used (just a basic pr.comment()) a few lines later, in the method which sends those pre-build comments: https://github.com/janinko/ghprb/blob/master/src/main/java/org/jenkinsci/plugins/ghprb/GhprbRepository.java#L236-L255 Hence right now, adding an extension to package org.jenkinsci.plugins.ghprb.extensions.comments which returns empty strings for postBuildComment() isn't enough to achieve the desired goal until addComment() is fixed to actually use postBuildComment() from extensions |
directhex
force-pushed
the
suppress-hello
branch
from
c5b08ef to
73eef3c
Compare
directhex
force-pushed
the
suppress-hello
branch
from
73eef3c to
f0daaf6
Compare
|
Can one of the admins verify this patch? |
1 similar comment
|
Can one of the admins verify this patch? |
This is helpful where you have multiple Jenkins jobs, all looking at the same repository - rather than spamming the user with multiple "Hello!" messages, you can pick one job to spam the user loudly, whilst letting all your other jobs silently obey the build/whitelist/etc comments