I want to trigger a build before pull request starts for merging (in Azure DevOps). For this option, I have added the Build validation under branch policies. But if I created a new Pull Request, I am getting the message as "Unable to queue build".
Please anyone let me know the option I selected solves my requirement. If yes, how to solve this "Unable to queue build" issue. If no, any option available to achieve my requirement.
Thanks
Your options is achievable, and the problem now is most likely caused by you triggering the pipeline in the wrong repository.
For example, if you create a pipeline from repository 1 and trigger the pipeline in a pull request created from repository 2, the pipeline will not be queued.
Modify your pipeline or PR repository so that the pipeline and PR use the same repository, this should be resolved.
I had the same problem and i changed the branch policy to include the build pipeline:
https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops&tabs=browser
Branch policy could be found from:
Repos -> Branches
Click on the 3 dots to the right of the branch that the PR is going to.
I was also facing the same problem, checking pipeline for being disabled or edited anyhow, but no differences.
But by checking the linked work items (tasks/pbis), I saw that one or more had not been completed. After changing the states everything worked fine.
Related
I am trying to create an Azure DevOps build pipeline. I have a script in the build pipeline that bumps up the version number, updates the version.h file and commits that file to the git repo. But as soon as this file is committed, the PR shows "Build Not Run":
I am using [skip ci] tag in the beginning of the commit message but doesn't resolve the problem either. I also tried adding "!/version.h; /*" as filters in the branch build policy. It still didn't make any difference. I have been trying to find solutions on google for a few days but it doesn't look like there are a lot of help posts related to this.
How can I make the Pull Request ignore the latest commit pushed from the build pipeline?
At a guess from the image I think this build is being triggered due to the branch policy of having build validation since it sates required check not yet run. Can you check the Build validation policy for this branch and check the build expiration. At a guess this is set to immediately, so when your build pipeline runs and updates the code it immediately invalidates the build validation. If this is the case adding the Path filter on the build validation to exclude the files you are updating should fix the problem
I've enabled the option - Settings/General/Merge Requests/Merge Checks - Pipelines must succeed.
Since then every merge requests automatically starts execution of the pipeline which is actually what i want. The problem is that this is running forever , i'm receiving message : Checking pipeline status
If i run the pipeline manually from CI/CD Pipelines - Run pipeline finish immediately. I don't understand what is wrong and why it stuck , can i check logs somewhere or something ?
For testing , the pipeline is really simple , just exit 1 .. but still not working ..
At this stage , "running pipeline" is not listed in pipeline list even if the status in merge request is
Checking pipeline status
We ran into a case where a merge request does not contain the .gitlab-ci.yml file. The fix is simply to do a rebase
For troubleshooting purposes, pipelines can be run manually on particular branches at CI/CD -> Pipelines -> Run Pipeline
For me what happened that .gitlab-ci.yml file was having issue as I have mentioned "master" as value for "only" label .. , then everything worked after updating it with my correct branch name which IMO should be "main"
Encountered this myself just now, using Gitlab shared runners. Tried re-running one individual job from the pipeline in the hope that it would resolve the issue. It did not. The best way is to change the commit id of the latest change in the MR.
You can either create an empty commit as suggested by #Bhargav11 or, to keep a cleaner commit history, do
$ git commit --amend --no-edit
$ git push --force
on your branch.
check if current branch you are checking the pipeline status and branch specified in "only: field" are same
only:
- master
This happens to me with pipelines that has no job that triggers on merge-requests.
If I have no tests or anything I wish to run during a merge requests I create a "dummy" job that doesn't do anything.
Rule to trigger on merge requests:
rules:
- if: $CI_PIPELINE_SOURCE == 'merge_request_event'
Then add a simple echo in the script section:
script: echo "Dummy job for merge-request"
Just add an empty commit to trigger it again.
git commit -n -m "commit comment"
From GitLab documentation:
"Checking pipeline status" message
This message is shown when the merge request has no pipeline
associated with the latest commit yet. This might be because:
GitLab hasn't finished creating the pipeline yet
You are using an external CI service and GitLab hasn't heard back from the service yet.
You are not using CI/CD pipelines in your project.
You are using CI/CD pipelines in your project, but your configuration prevented a pipeline from running on the source branch for your merge request.
The latest pipeline was deleted (this is a known issue).
I found what was wrong in my case. The problem was with the runners. There was "Shared runners" enabled by default which caused the confusion. I've just disabled them and enable my own runner and everything started to work as expected. You can check this in CI / CD Settings, I think they are enabled by default. Basically , pipelines are nothing more than a trigger for the runner... then the runner is responsible for the execution.
In our case, simply creating a copy of the branch (git checkout -b new-branch-name) and making a new MR with the identical code allowed us to work around the issue. The new MR pipeline executed successfully.
In my case, I had made a typo on the filename and had forgotten to add a dot before it.
Please ensure the filename is .gitlab-ci.yml
How did I debug this?
On the GitLab UI, I went into CI/CD editor and couldn't see my file.
I know this is a basic question but can someone explain with a scenario based on VCS like Git
A "PR" pipeline is just a pipeline that is triggered by a new pull request. It will usually run tests, static analysis, linting, or other checks against the incoming branch as a way to ensure coding standards are met before merging the PR. Azure DevOps will show the progress and result of the build on the PR page as well.
A CI pipeline is usually triggered when a specific branch is changed (perhaps master or develop). A build is automatically kicked off to run build/tests/static analysis/archiving/etc to ensure the new commits do not break things.
Here is more information from Microsoft that may help:
https://learn.microsoft.com/en-us/azure/devops/learn/what-is-continuous-integration
Hope this helps!
Updated 26-Feb-2020
In our Project, I have a pipeline "MyPipeline" which restores the NuGet packages, builds the solutions and runs the tests.
On the master branch, I have a policy which does things like add code reviewers, and it has a "build validation" step which executes "MyPipeline". All well and good.
However, I created another branch from Master called NewBranch and synced (pushed) this up to Azure. After doing some minor changes in Visual Studio, I did a merge from master, committed and sync'd to Azure.
I was a bit surprised then to see "MyPipeline" executing. It seems to have been triggered when I pushed my changes to NewBranch to Azure. I don't have a branch policy on "NewBranch". The trigger in the YAML file is:
trigger:
- master
What kicked this off? I'll soon burn through my free agent minutes if this continues...
Update 26-Feb-2020
As per the comments below:
The history of commits on the master branch are:
Tue 9:10 PM
Tue 7:47 PM
Mon 2:46 PM
The history of the pipeline execution show:
Wed 9:14 AM "PR Automated"
So, nothing new has been committed to the Master branch. However, I think I know what's causing this. Just that I'm not convinced on the timing....
So, we have two branches, master and NewBranch.
Master has a policy that requires two code reviewers to Approve, and it requires the build to succeed. Because of this policy, a developer can't therefore merge directly into master - they have to generate a Pull Request.
So, Developer A creates a Pull Request to merge NewBranch to Master. There is then the rather lengthy code review process which may take multiple additional commits to the "NewBranch"'s Pull Request before it's deemed acceptable.
What seems to be happening is that everytime one of these new Commits is sync'd to the Pull Request, a build is triggered. Is this a good thing? Maybe, Maybe not. If the build is going to trigger just once, then the compilation should occur when all the code in the Pull Request has been approved, not before hand. Why trigger a build at such an early stage; the master branch may be updated by multiple other Pull Requests before this is ready to be merged in. However, with unlimited resources, then I guess there's no harm in building as often as possible, but a) this can delay other builds (representing an impediment to other developers) and b) this uses up the free limit on agent time.
The detailed info you share in question is much help for me to understand the whole workflow of yours.
Though you did not express too clear, but, yeah, what you are guessing is correct. The action you faced is expected and by designed. The root cause is you are using branch policy and the Build validation also included into this policy.
The nutshell is you are using Pull request trigger.
Explanation:
Let's pay attention to its definition:
Pull request (PR) triggers cause a build to run whenever a pull request is opened with one of the specified target branches, or when
changes are pushed to such a pull request.
Based on your added contents, your developers are pushing changes (new commit) into the opening Pull request (Note: The key point is Pull request is still be opening.) This belongs to the work scope of the PR trigger because of above definition. That is why the build triggered every y new changes pushed into NewBranch branch.
Work around:
I agree with the logic of #devpro's answer. But its script does not available for your scenario. Because the pr in YAML only work for GitHub and Bitbucket Cloud repos.
Here you are using VSTS repo, and configured the policy for it. So, you can only via branch policy configuration to avoid such burning trouble.
In your Build validation panel, you are setting build policy with Automatic, right?
Please change the Automatic to Manual, also keep the Policy requirement value as Required.
Now, the corresponding build pipeline will not be ran automatically once new commit pushed, it can only built when someone run it manually.
For the delay timing you noticed which make you unsure, I guess it would because of conflict.
For sample, the Pull request P1 which merge from NewBranch to Master is opening. I commit a new change C1 into NewBranch. BUT, it causes the conflict. At this time, the build will not be ran because the changes does not actually pushed into PR.
Note: The commit is true to NewBranch. BUT changes does not accepted by PR yet, because PR detect out there has conflict here and you must tell PR which changes you want to keep. Only the changes pushed into PR can work with PR trigger.
Only the conflict solved, the changes, maybe I can say commit, can truly be accepted and pushed into PR. Then the triggered build ran.
This would be the time period delay you noticed.
I've seen the same behaviour today.
Can you try rewriting the trigger part in your pipeline like this:
trigger:
branches:
include:
- master
Does that help ? I can't verify it myself yet, since I've done that change but the PullRequest isn't approved yet :)
I've also another repository where I do not see that behaviour, but there, my pipeline trigger looks like this:
trigger:
- master
(Notice the 2 spaces before - master)
I think you need to add pr: none to your pipeline definition to disable the automated run.
If pr is not set I think the default is to run on every PR.
That would give something like this:
trigger:
batch: true
branches:
include:
- master
paths:
exclude:
- README.md
pr: none
I've been using Azure Pipelines for a while now and haven't changed my azure-pipelines.yml file here in 2 months. Previously, when there was a new PR, the pipeline would trigger and cause the environment to be built and the tests would be run.
Today, there was a new PR but I noticed that the pipeline was not being triggered. Then, to further test this, I forked, cloned, and branched the repository myself and created another new PR and, again, the pipeline was not triggered.
It's not clear to me where things are getting stuck and it's not clear how one would debug this. I've gone through this Azure DevOps documentation but it wasn't useful. I can manually trigger the pipeline to execute and test the master branch but I don't know how to manually trigger the same thing for a PR. Here's my Azure DevOps page for reference.
As normal, you do not need config pr in YAML script if there's no any special demand, we would do pull request trigger for all branches. But, it start broken from 03-13 21:02 (UTC), which caused by us, you do not do anything wrong.
The fix is preparing with our best.
As Alex said, this is the implicit trigger which YAML support only, if you do not configure pr in YAML explicitly.
To avoid such stuck later, except the method that Alex mentioned: add pr into YAML. You can also make use of UI configuration which performance is very stable until now.
Just go Pipeline definition page => Click on three dots of right corner => Select Trigger:
Then you will see Triggers tab which has Continues integration and Pull request validation display below. Open Pull request validation and enable Override the YAML pull request trigger from here:
Additional, Our team has noticed this broken issue, will update whether it is fixed here once we have any fixed release in progress.
Update 3/18/2020:
Fixed has released to all region. Every one can work github pr trigger as the document shows now.