Skip to content
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

Continuously rebuilding? #62

Closed
mmoss opened this issue Oct 8, 2015 · 40 comments

Comments

Projects
None yet
@mmoss
Copy link

commented Oct 8, 2015

We've been using this plugin for a while, and it's been great. We just tried breaking it out of our normal git-polling Jenkins job, into its own job. With a job setup that only uses this plugin it appears to continuously rebuild on the Cron interval (regardless of whether or not the PR branch has changed).

@fredsted

This comment has been minimized.

Copy link

commented Oct 26, 2015

Same here, with this plugin, it happens intermittently, leaving multiple comments on the PRs. It seems like it happens more when Bitbucket is a bit unstable? Anyone have a solution for it?

@fonsecas72

This comment has been minimized.

Copy link
Contributor

commented Oct 26, 2015

Same here, no solution though.

@samjonester

This comment has been minimized.

Copy link

commented Nov 3, 2015

Same here!

@msld

This comment has been minimized.

Copy link

commented Nov 18, 2015

same here!

On Wednesday, November 4, 2015 3:53 AM, Sam Jones <notifications@github.com> wrote:

Same here!—
Reply to this email directly or view it on GitHub.

@vladistan

This comment has been minimized.

Copy link

commented Nov 25, 2015

Same here

@nvartolomei

This comment has been minimized.

Copy link

commented Dec 15, 2015

same here :/

@vladistan

This comment has been minimized.

Copy link

commented Dec 15, 2015

I was able to solve the problem by making the job name to be exactly the same as bitbucket repository name

@tnguyen14

This comment has been minimized.

Copy link

commented Dec 16, 2015

As pointed out by @jwismar in #65, the reason for constant rebuilds seems to be

The behavior used to be that the plugin parsed the comments, newest to
oldest, and if there were no "Build Started" comments more recent than the
"test this please" then it would trigger a build. If that logic is still in
place, but we're no longer adding comments upon build start/completion,
then "test this please" is always going to be the most recent comment that
the plugin looks for.

@jwismar

This comment has been minimized.

Copy link

commented Dec 16, 2015

I do not believe that this is the same issue that I was referring to in the other thread, even though they have the same result. In the case of #65, we KNOW why we're seeing constant rebuilding -- after the PR to use the notification API instead of PR comments was merged, "test this please" comments are clearly going to trigger rebuilds.

This issue existed before that PR was merged, though. It happens sporadically; we have one build out of about 40 that seems to be affected, and haven't updated to the new version of the plugin yet. I don't have a good theory about what's causing it.

@saada

This comment has been minimized.

Copy link

commented Dec 22, 2015

Deleting the "test this please" comment fixes the problem for me.

@zabesto

This comment has been minimized.

Copy link

commented Jan 6, 2016

I have the same problem. I can't tell my users to manually delete the message every time.

@maxvodo

This comment has been minimized.

Copy link
Contributor

commented Jan 15, 2016

@saada, @zabesto Try my fork. Pull request build one time. If you wrote comment with "test this please", Jenkins rebuild this pull request and delete this comment.

@jonathanhle

This comment has been minimized.

Copy link

commented Jan 19, 2016

+1, after upgrading the plugin if "test this please" is in the PR's comments, Jenkins will continously rebuild it.

@jonathanhle

This comment has been minimized.

Copy link

commented Jan 19, 2016

@mmoss can you send a pull request to @nishio-dens, to get your fix upstream?

@mmoss

This comment has been minimized.

Copy link
Author

commented Jan 19, 2016

@jonathanhle if we had a fix I would. Right now we've undone our changes...

@maxvodo

This comment has been minimized.

Copy link
Contributor

commented Jan 26, 2016

👍 Ready for production @96ab7a75f14d9990f3c8f1255f9790c496a64473

@mmoss

This comment has been minimized.

Copy link
Author

commented Jan 28, 2016

@maxvodo Works great!

@maxvodo

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2016

Also check #71 for details about test this please comment behaviour

@tnguyen14

This comment has been minimized.

Copy link

commented Feb 1, 2016

Other than the test this please issue, I am seeing this behavior if the bitbucket user does not have read access tot he source repo of the pull request. Anyone else seeing it?

@Mercynary

This comment has been minimized.

Copy link

commented Feb 2, 2016

Since the update to 1.4.13 the jobs are continuously rebuilding and not even waiting for the prior build to finish. I got over 1k builds over night.

@pdjtrifork

This comment has been minimized.

Copy link

commented Feb 2, 2016

@Mercynary this happened to me as well....I had set the CI Identifier/Name plugin parameters to a (custom) value containing the underscore character. Not sure that was the problem - I just gave up fixing it for now, as setting both values to 'Jenkins' made things work as expected, ie. no endless rebuilding/scheduling of jobs. Might have something to do with how the plugin determines wether a new PR should be build or not.

@maxvodo

This comment has been minimized.

Copy link
Contributor

commented Feb 2, 2016

@tnguyen14 @Mercynary Oh, thete can be serious problem. TTP comment test this please allow rebuild job all times, until build comment [bid: #...] not found in thread. So, account for check PR comments status must have write access (for posting [bid: #...] comments).

Please, open new issue for this repo.
Possible worst workaround: manual delete TTP test this please comment from thread.

@tnguyen14

This comment has been minimized.

Copy link

commented Feb 2, 2016

@Mercynary same, I got over 2k builds over the weekend, with like 5-6 PRs.

@maxvodo are you referring to write access for the destination repo, or the source repo? The jenkins user has write access to the destination, but only read for the source.

We don't use the TTP comment, just an SCM checking, so there's nothing for us to remove.

We are on version 1.4.13.

@maxvodo

This comment has been minimized.

Copy link
Contributor

commented Feb 2, 2016

@tnguyen14, @Mercynary, @pdjtrifork: could you post here (or make gist) your log?
All strings from Manage Jenkins > Logs > All Jenkins Logs by bitbucketpullrequestbuilder.bitbucketpullrequestbuilder template.

@pdjtrifork I will check your "underscore character" guess.

@tnguyen14

This comment has been minimized.

Copy link

commented Feb 2, 2016

@Mercynary

This comment has been minimized.

Copy link

commented Feb 2, 2016

@maxvodo - here's [1] my gist. It seems that the key is too long.

[1] https://gist.github.com/Mercynary/0a09a59dd24d4cd5726d

@pdjtrifork

This comment has been minimized.

Copy link

commented Feb 3, 2016

@maxvodo Our logs have long since rotated so no can do, sorry.
My bet is that we saw the same issue as @Mercynary with too long identifiers. The CI identifier/Name I chose would have been above 40 chars when the commit hash is concatenated, while just using 'Jenkins' does not exceed this limit.
The default value (when not configured explicitly in the job parameters of Jenkins) is null, which works fine btw - no NPEs :) So I figure only users that configure all of the parameters would see this issue. Or this may be a side effect of updating the plugin rather than doing a clean install...

@tnguyen14

This comment has been minimized.

Copy link

commented Feb 26, 2016

Hi all, I'm noticing this continuous rebuilding behavior very consistently for PR that comes from a source repo we do not have read access to. Is there a way this can be fixed?

@maxvodo

This comment has been minimized.

Copy link
Contributor

commented Mar 3, 2016

@tnguyen14 Plugin uses BitBucket API to post build status for each PR, so at this moment it can't be fixed. I will see what I can do to save build status into other destination (maybe persistence file).

@ssasaki

This comment has been minimized.

Copy link

commented Mar 6, 2016

By using bitbucket-build-status-notifier-plugin(a jenkins plugin), I can avoid the continuous rebuilding behavior for some reason.

From reading code, I found that this bitbucket-pullrequest-builder-plugin uses 'hasBuildStatus()' as the variable 'commitAlreadyBeenProcessed'. This seems to mean the variable 'canBuildTarget' will be always true without build status, and cause the continuous rebuilding... maybe?

Anyway, in my case, after creating build status by using bitbucket-build-status-notifier-plugin, the endless rebuilding/scheduling befavior is stopped.

The plugin version I tested are
1.4.16 Bitbucket Pullrequest Builder Plugin
1.0.3 Bitbucket Build Status Notifier Plugin

Hope it's helpful.

@jkobus

This comment has been minimized.

Copy link

commented Mar 29, 2016

I've had this issue due to "unset" jenkins url (it was set, but after re-setting it it worked).
Message in log was:

PLEASE SET JENKINS ROOT URL IN GLOBAL CONFIGURATION FOR BUILD STATE REPORTING

see jenkinsci#1

@DoDoENT

This comment has been minimized.

Copy link

commented Jun 6, 2016

I've had this issue because jenkins url was set to 'http://servername/jenkins' - BitBucket API treats such URL as invalid. I had to rename it to 'http://servername.local/jenkins' to make it work.

@houmie

This comment has been minimized.

Copy link

commented Jun 10, 2016

@DoDoENT I have the same problem, would you kindly elaborate your solution a bit more? e.g. The jenkins url is setup in our case is like http://jenkins.company.com How am I supposed to change this please?

@DoDoENT

This comment has been minimized.

Copy link

commented Jun 10, 2016

@houmie, I fixed that problem accidentally while working on similar issue on another plugin. Basically in Jenkins global config under Jenkins location I've changed the URL in a way I explained before and everything started working out of the box.

The continuous rebuild behaviour is caused by plugin not being able to set build status of the pull request to INPROGRESS and when it checks next time for new pull requests it will skip those that already have any status set. The wrong URL is just one possible problem causing BitBucket API to return error response. It would be much easier to understand the problem and fix it if plugin author would add logging of each request to BitBucket and API response - by doing that in BitBucket Build Status Notifier Plugin I could quicky find out that my URL was wrong - in your case something else may be wrong (credentials, something else?).

I urge plugin authors to add verbose logging of each request and response (possibly configurable) so it would be easier for Jenkins users to determine what they have configured wrong - maybe everything is OK, but some company firewall is preventing BitBucket API requests - by having each request logged, one could simply replay those requests with curl or wget and quickly find out what is wrong.

@dPeS

This comment has been minimized.

Copy link

commented Jun 22, 2016

pls don't close this issue till docs won't be changed, thanks

@houmie

This comment has been minimized.

Copy link

commented Jun 22, 2016

@DoDoENT I still haven't been able to make any progress on this. The credentials are correct because the pullrequest tests are passing. But these tests keep getting repeated. There is no end to it.

You mentioned that I needed to change the URL to 'http://servername.local/jenkins'
Could you elaborate on this? Our server URL is http://jenkins.company.com what do you mean by .local?

@DoDoENT

This comment has been minimized.

Copy link

commented Jun 23, 2016

@houmie, please read comment thread from this issue.

In our case, Jenkins URL was set to http://servername/jenkins and when such URL was sent to BitBucket via their API, BitBucket returned error "Invalid URL" which was not handled at all by plugin and kept continuously rebuilding our pull requests because it thought that build was not in progress. After setting Jenkins URL to http://servername.local/jenkins or http:///jenkins, BitBucket API started accepting the URL and everything started to work for us.

But in your case it may be possible that some other error appears. Please check Jenkins logs to see what happens.

@taz77

This comment has been minimized.

Copy link

commented Oct 24, 2017

I had this issue and the item that @DoDoENT pointed out was the fix. I had my Jenkins URL set to an internal network hostname http://jenkins:8081 I changed it to something like http://jenkins.server.local:8081 and now builds work right with triggers in comments.

@ruschecker

This comment has been minimized.

Copy link

commented Sep 28, 2018

same here

@CodeMonk

This comment has been minimized.

Copy link
Collaborator

commented Sep 28, 2018

@ruschecker Same here that the fix mentioned by @DoDoENT and @taz77 works?

Or, same here that you are seeing the issue?

@CodeMonk CodeMonk added the aged out label Oct 8, 2018

@CodeMonk CodeMonk closed this Oct 8, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.