-
Notifications
You must be signed in to change notification settings - Fork 612
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
Test phrase comments on PRs not triggering build #450
Comments
Check the system (jenkins) logs, it's mostly because you are not specifying a secret on github. |
Is that a change since 1.33.1? |
@AudriusButkevicius to be explicit: this is a new bug that does not occur with 1.33.1. My underlying configuration has not changed, and downgrading fixes it. |
I think some specific version started enforcing secrets, so not much of a bug but a security feature. Regardless, you should look at the logs and you'll know if thats the problem or not. |
@AudriusButkevicius yup that fixed it. You're my hero :) |
Looks like there still may be a bug here. I had to do one of them twice for it to register and sure enough the log reflects that:
|
Well the log still talks about signature mismatches which implies there is still a secret missing somewhere |
Seems like it's just randomly dropping some of them. |
OK I just fired off 5301, 6566, 5986, 5950, 6750, 6764, 5490, 5756, 5828, 5881, 6620, 6936, 6451, 6982 in quick succession. It looks like only 5301 and 6566 actually triggered the build. So looks like I'm going to have to downgrade again :( |
Well this is weird: https://bot.brew.sh/job/Homebrew%20Core/12736/version=any_sierra/console Um, wow ... :)
|
OK, I downgraded and now all builds triggered as expected. So I'm going to need to leave it on the older version for now since this has to work or the other Homebrew maintainers will probably do something unpleasant to me :) |
@ilovezfs Interesting. And, just from a high-level, when upgrading to the latest, did you restart services? Did you happen to look at your logs with the FINE setting to see more detail from ghprb? |
Yeah, I unloaded the plist and then reloaded it.
Nope. You'll have to tell me a bit more about how to do that and where the log files are that you want because I'm quite Jenkins-ignorant. |
@ilovezfs Sorry I'm not sure what you mean by plist In terms of logging, you can peek in on more fine-grained logging in particular plugin classes. Here's a screenshot of a logger we set up. To set up a logger, go to Manage Jenkins > System Log, then use the "Add new log recorder" button. |
Hi - I've been looking at this issue this morning, and have not been able to reproduce it. I wonder if you could provide more details? |
Hi all, found this while debugging a very similar issue. We just upgraded to the latest, this was working fine before (unfortunately I didn't write down which version we had previously but it was >1 year old). I enabled the custom logs as suggested above, and our logs mention "Use webHooks is set, so not running trigger". We have the "Test phrase" setting set in the global settings ({serverurl}/configure) which is set to the default regex ".test\W+this\W+please." The specific jobs did not override this setting (the field left empty) but we noticed now that actually stating it explicitly in the job fixes the missing build trigger. Possibly a problem with how the blank setting is interpreted? We are also seeing new PRs not being triggered, but couldn't identify a pattern yet. Our CI is publicly accessible, in case that helps this is one of the jobs triggered by github PRs: http://ci.hibernate.org/view/Search/job/hibernate-search-PR/ |
I believe I am starting to see the same problem. I recently enabled "Only use trigger phrase for build triggering" on a project that was overwhelming our job queue. We decided to establish a process to require the trigger phrase from an admin when a PR was ready to be built, but the result is that none of the PR's are built with this option enabled. I have tried statically setting "test this please" as the global test phrase, and "ok to test" as the trigger phrase globally and on the specific project, with no effect. If I disable/uncheck "Only use trigger phrase for build triggering", test phrase triggering works properly. It is behaving like a regression of: janinko#153 |
Here's a logging example of the behavior with the option enabled, and without the option enabled: === With “Only use trigger phrase for build triggering" enabled ===
=== Without “Only use trigger phrase for build triggering" enabled ===
|
Some more details -- when trying to use the retest phrase it claims that the target branch is either not listed in the whitelist, even though it is -- or that it is not triggered. I haven't been able to figure out the context of the logs in regard to which job/branch the PR poll is performed for/by. Is this plugin only supported to be used as a single Jenkins project for PR builds against an entire github repo? We have separate jobs created for each branch, in our configuration. From the master branch PR builder job's config.xml:
From the org.jenkinsci.plugins.ghprb.GhprbPullRequest logger:
Another run
|
In my configuration, I forgot to mention that the trigger phrase works fine when |
Just an update for the issue I was seeing, that I side-tracked this issue with -- it appears that the conditionals for triggering the build trigger are mutually exclusive, which has the potential consequence of short-circuiting if any trigger/whitelist/test phrases match one another (through regex or exact match). Maybe this is similarly impacting what other users are seeing here? I opened a separate issue here: #499 |
I am having the same problem. I don't have a "trigger only" choice in the configuration, only "auto-manage webhooks" which i have enabled. I don't want to break the current operation of the PR builder, which is great, and automatically creates PR builds when new commits are made. I want to add the ability to rebuild a PR with a magic phrase. (and branches too, idk if this is the forum for that.) When i enter "retest this please", the build is not triggered, and I can see this in the log:
Another observation is that there appear to be entries in the log, each one minute apart, for one comment. The following is for four comments:
|
Jenkins 2.19.4, ghprb 1.33.4
Seems that leaving
isn't triggering the build.
Configuration:
The text was updated successfully, but these errors were encountered: