问题
I am using a local BitBucket server with Git. I am trying to get started with Continous Integration so I've set up a local Jenkins instance. The goal is to have Jenkins check out pull-requests and build the project, and then report back to BitBucket with the result.
In BitBucket I am using Webhook to Jenkins for Stash which notifies my Jenkins instance each time a pull-request is created/updated.
In Jenkins i am using Stash pullrequest builder plugin to have Jenkins checkout the pullrequest, when notified from the plugin above. I have used the settings in the documentation, i.e.
Refspec: +refs/pull-requests/*:refs/remotes/origin/pr/*
Branch Specifier: origin/pr/${pullRequestId}/from
It almost works...
When i create a new pull request in BitBucket, Jenkins get nofitied, checks out the PR and report the result back to BitBucket. So far so good.
However when I update the PR (i.e. commit new code and push to BitBucket), Jenkins gets triggered but still checks out the previous commit in the PR, and not the new commit.
I've done some investegation but got stuck. From what I understand Refspec
specifies that i should map refs/remotes/origin/pr/*
to refs/pull-requests/*
locally. However it does not seem like BitBucket updates the refs for the PR when i do a new commit to an existing PR, which causes Jenkins only to find the old one.
When I run git ls-remote origin
after commiting and pushing an update to an existing PR i get this:
edf245 (new commit)... refs/heads/feature/Name-Of-My-Branch-That-I-Created-Pull-Request-From-pr
af774f (previous commit in PR)... refs/pull-requests/69/from
7fa82b (master)... refs/pull-requests/69/merge
However after visiting the PR-page in BitBucket, the refs seems to be updated and i get the following result:
edf245 (new commit)... refs/heads/feature/Name-Of-My-Branch-That-I-Created-Pull-Request-From-pr
edf245 (new commit)... refs/pull-requests/69/from
7fa82b (master)... refs/pull-requests/69/merge
And if i manually trigger Jenkins after this it build the latest commit.
So my problem is that BitBucket does not seem to upfate the refspec until I visit the acutal PR-page in BitBucket. How can i fix this?
Googling the problem I ended up here where it seems like the behaviour is by design...
回答1:
See Daves answer for an explanation on why this "problem" arise and why Bitbucket is designed in this way.
However i was able to solve my specific problem by changing the settings in the Jenkin-plugin, to "trick" Bitbucket into updating the refs.
By setting the option Build only if Stash reports no conflicts
to true in Jenkins (Under Build Trigger
for the job), you force Bitbucket to update the refs which means you will check out the correct commit
See https://github.com/nemccarthy/stash-pullrequest-builder-plugin/issues/75 for details
回答2:
Full disclosure: I work for Atlassian's Premier Support team.
First of all, this isn't a bug - it's worth noting that pull request refs (under refs/pull-requests/*
) are an implementation detail of Bitbucket Server. They are not intended to be used for CI, or generally relied upon for development. This comment by one of our developers lists some of the reasons why it might not be a good idea to build these refs in CI.
To give you a more technical background, these refs are only created when the pull requests are viewed - they're not eagerly created. Further, the refs under /refs/pull-requests/*
may be updated at any time - any change to the source or target branch will result in the pull request being rescoped, but this rescoping event is not guaranteed to be instantaneous and may be enqueued alongside other system events. This is one of the main reasons why we don't recommend building off them. There are other good reasons not to build off these refs - considering the following scenario:
- Sarah at Apple opens PR #123 in ios-core, to merge feature/hologram-ui-support into develop (I know, I'm a dreamer)
refs/pull-requests/123
is created, and a CI build runs for the feature/hologram-ui-support PR- Meanwhile, Ahmed merges bug/weird-apfs-edge-case into develop. This causes
refs/pull-requests/123
to be rescoped because the target branch has changed, and another CI build runs for the feature/hologram-ui-support PR - Jane merges feature/siri-asimov-laws-of-robotics-support into develop.
refs/pull-requests/123
is rescoped again, and another CI build runs for the feature/hologram-ui-support PR
You can see what I mean - because those refs get rescoped on changes to the target as well as the source branch, it results in a lot more CI builds than you might be expecting. This is likely to be very taxing for your CI server, as effectively every merged PR will trigger a build of every open PR.
Generally speaking I'd recommend one of two approaches:
- Build the merge in your CI build:
- Trigger builds on changes to the source branch, and have your build plan do something like
git checkout target; git merge source
as a build step. Most CI systems should have native support for this kind of workflow.
- Trigger builds on changes to the source branch, and have your build plan do something like
- If you must build off
refs/pull-requests/
, do so only onrefs/pull-requests/<id>/merge-clean
. There are other merge types here that are inherently failure cases:merge-conflicted
andmerge-base
, so there's no point even trying to build those.
Cheers,
Dave
来源:https://stackoverflow.com/questions/48806891/bitbucket-does-not-update-refspec-for-pr-causing-jenkins-to-build-old-commits