ip1981 / bbprb Goto Github PK

Delete build status when build is cancelled manually, instead of setting it to "FAILED".

I am trying to use this with the following setup:

• teamOwner/repository-foobar
• user/repository-foobar (fork of teamOwner/repository-foobar)
• PR is created from a branch on user against teamOwner/repository-foobar

This does work with the "cron bitbucket jenkins plugin". However with bbprb, it only works if I set the repository url within jenkins to the following:

[email protected]:${bbprbSourceRepository}.git

however, internally the plugin will still try to use dest* for the build-status, which will not work because the dest does not have the commit-hash of the src.

E.g. builds work, but build-status api does not work.

trying to implement the plugin I am receiving the following error from bitbucket:

this sounds like csrf issue? But I did compare with https://github.com/jenkinsci/bitbucket-plugin/blob/master/src/main/java/com/cloudbees/jenkins/plugins/BitbucketHookReceiver.java#L20 so not sure what is going wrong?

Is this plugin compatible with Bitbucket Server? I configured the webhook but every time it is fired I am getting 400 status code. Thank you!

Get this plugin into plugins.jenkins.io so it can be auto-installed

Cancel builds when a PR is merged. Add a boolean option: true = cancel, false = don't, default: false

would be nice if this had travis integration for reliability reasons...

it would be great if it could support the PR-comment trigger as well, that way a manual trigger can be done when posting a comment "please build" (configurable) in the PR.

Cancel builds when a PR is declined. Add a boolean option: true = cancel, false = don't, default: true

Hi, love the plugin, it's awesome. Thank you.

I am running BBPRB v.0.3.0 on Jenkins v.2.121.2.

I recently converted a job from a normal build to a pipeline workflow - it allows easier access to doing programmatic search for ambiguously defined dependencies (sigh). Ie I can search other builds to find products of a similarly named branch in a separate repo.

Unfortunately now when I do this I now get stack traces in my jenkins backend when the job should be triggered:

WARNING: Error while serving https://jenkins.protmv.com/bbprb-hook/
java.lang.reflect.InvocationTargetException
	at org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:347)
[...]
Caused by: java.lang.NullPointerException
	at org.jenkinsci.plugins.bbprb.BitbucketBuildTrigger.abortRunningJobsThatMatch(BitbucketBuildTrigger.java:214)
	at org.jenkinsci.plugins.bbprb.BitbucketBuildTrigger.startJob(BitbucketBuildTrigger.java:156)
	at org.jenkinsci.plugins.bbprb.BitbucketBuildTrigger.handlePR(BitbucketBuildTrigger.java:282)
	at org.jenkinsci.plugins.bbprb.BitbucketHookReceiver.doIndex(BitbucketHookReceiver.java:108)
	at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:627)
[...]

Looking at the code there (Note, I've added the WARNING logging):

  private void
  abortRunningJobsThatMatch(@Nonnull BitbucketCause bitbucketCause) {
    logger.log(Level.FINE, "Looking for running jobs that match PR #{0}",
               bitbucketCause.getPullRequestId());
\\    logger.log(Level.WARNING, "job: " + (job != null? job.toString() : "null - no job"));
\\    logger.log(Level.WARNING, "job-builds: " + (job.getBuilds() != null? job.getBuilds().toString() : "null - no jobbuilds"));
    for (Object o : job.getBuilds()) {
      if (o instanceof Run) {
        Run build = (Run)o;
        if (build.isBuilding() &&
            hasCauseFromTheSamePullRequest(build.getCauses(), bitbucketCause)) {

the logging shows the this.job is null.

It looks like WorkflowJob does not have AbstractProject as an ancestor, and maybe this explains this behaviour in some weird way. A quick search shows this seems to be on "purpose".

I looked at quickly adding something that would work but realized that my first thought of checking types in startJob for ParameterizedJob would fail as scheduleBuild2 there lacks the necessary signature.

I don't understand why this.jobs is null in that later method so I'm pretty sure I don't understand what's going on.

Am I missing something?

Make builds implicitly parameterized, so that rebuilding a PR really works with the same hash. Refer to the ghprb plugin: it uses an implicit parameter named sha1 .

Basic documentation would be nice :)

Starting tomorrow, the username field will be completely removed from the author field for the pr json coming from bitbucket cloud. I think you can likely replace it with display_name to fix the issue. Currently the code is breaking for some user prs when it queries the username field from json because it is missing.