In simple words please,
What is the meaning of "build expired" when creating a pull request?
All answers I found are the same, from microsoft website.
Thank you very much!
What is the meaning of "build expired" when creating a pull request?
"Build Expired" is a feature of branch policies. Set a build expiration to make sure that updates to your protected branch don't break changes in open pull requests.
In short, when the target branch is updated before the pull request is completed, build expiration will be triggered.
For example:
Pull Request: Release -> Master. Master branch have other new changes during the Pull Request Process. It will trigger the Build expiration.
You can set the expiration time according to your needs:
Immediately when branch is updated.
After n hours if branch has been updated
Never
You can navigate to Repos -> Branches -> Branch Policy -> Build validation to check the detailed settings.
Build expired when creating pull request
From you situation, you may have set the first policy: Immediately when branch is updated.
When you see the build expired, this means that the target branch has some new changes.
To solve this issue, you can choose a suitable policy for build expiration.
Here is the doc about branch policy.
Related
My team is using BitBucket for Git repositories. We plan to go live in next two months and what I want to do is to limit so that the pull requests can be only made from a specific branch to the 'production' branch.
I am aware of the Branch Permission sections of the BitBucket but that solves by limiting the 'Changes without a pull request' only half the issue.
What I want to achieve is that there should be no changes allowed without approved pull request and this pull request can only be made from a specific branch.
If the pull request is made from any other 'random' branch to the 'production' branch the pull request could get automatically denied.
Is such a thing possible? Thanks.
I cannot find an option to delete a PR on BitBucket.
Am I overlooking something or it's really not possible?
You can decline a pull request which has the same result -- stopping / removing the PR.
As per the link jonrsharpe mentioned, to the right of the merge button there are 3 dots. Under that menu you should have a delete option if you have permission to delete.
This is available only for BitBucket Server, not on BitBucket.org.
In BitBucket.org there is no option to delete the PR.
For Bitbucket Cloud, there are no way to do this. One way of getting by is to have a 'dev/junk' branch, used for declined or useless pull requests.
Then just edit the existing request to go into this branch and merge.
Data is still there, in case you need it some day, or if it's sensitive info you can remove the whole branch. If its already declined before, well, nothing can be done then other than recreating that repo
See https://jira.atlassian.com/browse/BCLOUD-8089 for the update on this feature request and vote on it!
I wanted to delete a pull request of a branch that had already been merged and deleted. Even though I am an admin of my project, I cannot see any "delete" options. For me what worked was to recreate the deleted branch from the main branch and push it. E.g.
git checkout master
git checkout -b [deleted branch name]
git push -u origin [deleted branch name]
Then I opened Bitbucket and the branch showed up as "merged" and disappeared from the PRs list.
You cannot delete the PR in bitbucket.org .
Using Decline option will do exactly what you want - the PR won't be visible in the tab Pull requests (you need to sort PR by Decline to see it) but on tab Branches you will see that in column Pull request you have removed your problematic PR.
PS you cannot undo Decline of PR, so take care
Hoping to gather insight from professionals. My end goal is to trigger a jenkins build whenever a bitbucket pull request happens. If anyone could give me an ELI5(explain like I am 5) answer it would be greatly appreciated. Sorry if this is the wrong format, I am new to jenkins and stackoverflow.
What I have done so far:
Created webhook in bitbucket and gave the url to my jenkins job. example: http://jenkinsURL:8080/job/boulevard-dev/generic-webhook-trigger/invoke?token=myPull_Request_Token
Pull request webhook trigger
In Jenkins, under source code management I have: Source Code Management Settings. This is currently fetching a ton of branches, failing, then building the master branch when the job starts?
For build triggers, other stackoverflow articles have pointed me to the "Generic Webhook Trigger". https://github.com/jenkinsci/generic-webhook-trigger-plugin
I am not entirely sure how this generic webhook trigger should effectively be setup? Hoping someone has experience using it and could explain what is needed.
This is what have seen referenced in other articles.Build Triggers settings Build triggers settings 2
Questions:
What does a correct setup / example of the generic webhook trigger look like?
Currently, my job triggers when a change is made to master or merged to master, how can I specify to my job that I want the bitbucket pull request branch to be built?
Also, I found this, not sure if its related to my issue or not? https://jira.atlassian.com/browse/BCLOUD-5814
As per your requirement, you can trigger a Jenkins build whenever a bitbucket pull request happens by following the below steps, in my case, it's working fine.
Step(1) - Configure Jenkins
(i) Add your bitBucket repo and branch to source code management
(ii) On build Triggers setup Poll SCM to * * * * * for run every minute to check pull request from bitBucket.
Step(2) - configure Bit Bucket Hook
(i) Go to settings and add a new hook, now setup pull request trigger as per your requirement.
Step(3) - Make a pull request and see the new job automatically triggered on Jenkins.
I already merged a pull request in bitbucket. Can you all explain what is the difference between click Approve and don't click it?
Because I see that the merge commit still appears in git history/log even that I don't click Approve.
If your team has a Premium plan, repository admins can prevent pull requests that don't have a certain number of approvals from merging.
Other than that, it is a visual check only that the merge request was reviewed and approved prior to merging.
See: https://confluence.atlassian.com/bitbucket/pull-requests-and-code-review-223220593.html
I am running tfs 2015 and have it build when a pull request is create to a certain branch.
It appears that the retention policies are not working on it as they should be only lasting 1 day and they are there for months at a time.
I think the problem is the source branch. on the pull requests builds it has it as the refs/pull/688/merge. The retention policies look for refs/heads/*.
Is this why they are not getting deleted and if so how can I add the pull request builds to get them deleted?
I have tried typing refs/pull/* in the retention but it comes back as refs/head/refs/pull/*
This is due to the refs/pull/688/merge branch was created and only for the build of pull request. However, the normal branch is refer/heads/(master/feature/...). It's not in the branch filters of normal branch. So the build retention has no effect on the pull request build.
For now, you may have to delete the pull request builds manually. You can also add a user voice in this site for this feature request. PM will kindly review it.
It's explained in Microsoft's documentation here. Your Minimum to keep is not zero, so there will always be something kept for the pull requests "branches".
In your case you want to add a new retention policy with 1 for Days to keep 0 for Minimum to keep and refs/pull/* for Branch specification / Branch filters
In 2017 (local, not VSTS) typing /ref/pull/* doesn't work, you end up with +refs/heads//ref/pull/* - the + being the include. Typing refs/pull/* works fine and you get +refs/pull/*