I have 4 Azure Pipelines that perform checks when a PR is created. They are configured such that certain checks are excluded/included based on the changes made. For example, if the PR only contains frontend code changes, there is no reason to run the check pipeline associated with checking backend code changes.
In the GitHub branches configuration, there is an option "Require status checks to pass before merging" but when you check that you have to select which pipelines must pass. Doing so sets it so that the pipeline you selected must run and pass in order to merge, but with our configuration, it may not have a reason to run so the PR would be stuck forever.
Is there a way to have GitHub status checks required to pass before merging, but the status checks that must pass are determined at the time of the PR creation, not beforehand?
Based on my test, I could reproduce this situation.
When I create multiple status check(Azure Pipeline) in Github, these checks only accept the build status after the Pull Request was created.
Therefore, due to some configuration (such as path filter), if the related pipeline does not run, then this PR will be stuck.
In this situation, you could use API to send the existing Azure Pipeline Status to Status check.
API URL:
Post https://api.github.com/repos/{owner}/{repo}/statuses/{sha}
Reuqest Body:
{
"state": "success",
"target_url": "Build Status badge Url",
"description": "Build verify",
"context": "Staus Check name"
}
Then you could pass the status check in Github.
Related
I have created a custom PR status check to validate my PR follows a conventional commit like pattern. This is in Azure Devops Git, not Github. To do this, I created an Azure Function App and setup a status check in Azure Devops. Here is the configuration:
I enabled the PR status check for my branch. Here is the config for that:
The PR status check appears and actually works....when I invoke the call manually. I can use postman to invoke my function (with a PAT I generated for my account) and it will update the status on the PR. But if I commit to the branch, the step sits there on the validation step even though I have the checkbox checked to "Reset status when there are new changes".
This is what it looks like after I invoke the function manually through postman
I would expect the system (AZDO in this case) to invoke my function every time a new iteration was created (i.e. when a new commit is pushed to the branch). Can someone point out what I'm missing? Thanks!
Ended up coming up with solution. I don't have privs to add a an authenticate an application to run the pipeline because of the way our org is setup. So I created a node script to accomplish what the function app is supposed to do.
I have a duplicate pipeline let us call is A and B. I have disabled pull request validation for the pipeline B, however despite the change when a pull request is raised A and B still both run, and what is worrying is that because automation execution has been disabled for pipeline B, it holds up the pull request and becomes a blocker. The way around is to manually run pileine B.
I cannot seem to remove pipeline B from the validation checks for pull requests. How can this be done ?
I have two same pipelines in Azure DevOps. "EnablePR-A" and "DisablePR-B".
The trigger setting is as below:
When a PR is made in GitHub repo, A is triggered.
To check the trigger setting in your pipeline:
Also, you could check how your pipeline is being triggered:
I have been reading the Azure Devops docs and I am completely confused by them. All I want to is something very simple (simple with Github Actions in Github anyway) where
A developer creates a PR.
As the PR is created Azure runs all the associated Cypress tests
If any fail then the notes at the top of the PR indicate this. For example just next to the bit where it says 'there are merge conflicts'
We had this working in Github, but I can't figure it out here.
Thanks
There is no extension like "Cypress GitHub app" in azure devops, so it is impossible to achieve exactly the same function as in github pull request.
As a workaround , you can try to add status policy.
Using status alone, details from an external service can be provided
to users within the PR experience. Sometimes, sharing information
about a PR is all that is necessary, but in other cases PRs should be
blocked from merging until requirements are met. Like the in-box
policies, the Status policy provides a way for external services to
block PR completion until requirements are met. If the policy is
required, it must pass in order to complete the pull request. If the
policy is optional, it is informational only, and a status of
succeeded is not required in order to complete the pull request.
External services can use the PR Status API to post detailed status to your PRs. The branch policy for external services brings the ability for those 3rd party services to participate in the PR workflow and establish policy requirements. This article guides you through the process of configuring a branch policy for a service that is posting PR status.
In addition, here is a ticket about how to create required pull request status check, you can refer to it.
I have a pull request trigger for Github in VSTS. I also want to add this trigger to the required checks in Github and show build status on pull request page like below.
I also checked branch protection page on Github but there are no status checks available.
Is it possible to do this in VSTS or do I need to create a PR status server mentioned here ?
I checked Advanced settings => Report build status option and VSTS automatically sends commit status to Github.
Configuration for enabling the GitHub commit status checks in Azure DevOps seems to have changed.
Ensure Azure Pipelines is installed for your organization or repository
Edit your Azure DevOps Build (Pipeline)
Click on the Get sources step
Under the GitHub configuration, select Report build status
Save (& queue, if you wish) your updated configuration
If someone on the DevOps team sees this, reporting commit status should be enabled by default!
There isn’t such setting in VSTS, you can refer to this workflow to do it:
Get a commit sha
Create a status check context through REST API
Post: https://api.github.com/repos/[owner]/[repository]/statuses/[commit sha]
Body(application/json):
{
"state": "success",
"target_url": "XXX",
"description": "Build verify",
"context": "continuous-integration/vsts"
}
Then check the related status check in branch protect page:
Note: the target_url can be badge URL (Check Badge enabled in Options of build definition)
Create a build definition to create status through REST API (The same as step 2: change commit sha and body) in VSTS continuous integration (Enable continuous integration) for current commit
Create a build definition to update status of current commit through REST API in VSTS (Enable pull request validation)
From Jenkins, Pull-Request Status can be created/updated from pipeline
script {
pullRequest.createStatus(status: "success",
context: "validate-profiles",
description: "Profiles file validated successfully!",
targetUrl: "$RUN_DISPLAY_URL")
}
Tons of other things can be done from pipeline avoiding explicit calls to GitHub API
Make a comment on Pull-Request
pullRequest.comment("Your service-profile request is received. Please track ticket progress here: "+ticketData['_links']['web'])
Create & Add Labels to Pull-Request
pullRequest.addLabel(env.TICKET_ID)
Update Title for the Pull-Request
pullRequest.setTitle("["+env.TICKET_ID+"] Profile Review Request for "+env.CHANGE_TARGET)
I'm trying to set up an automated CI process GitHub and Jenkins. The goal is to have developers create feature branches and generate pull requests that are automatically merged (if they pass build, of course) using Jenkins Github Pull Request Merger.
It is a further goal to require that pull requests be against an open GitHub issue. For us, that means that either the pull request title or at least one of the pull request commit messages must contain a substring like "fixes #NN" where #NN must reference an open GitHub issue. This 'issue_opened' check is also automated - our 'issue_opened' GitHub App queries the GitHub issues and examines commit messages and the PR title, then it POSTs the pull request with a status (for testing purposes I'm always posting 'failure').
The process envisioned is as follows:
1. Feature branch pushes are automatically built by Jenkins.
2. When a feature branch is ready and passes Jenkins testing, a developer will generate a pull request; this automatically triggers steps 3 & 4, each running independently:
3. Our 'issue_opened' GitHub App very quickly POSTs a status to the pull request.
4. Jenkins performs the build - it takes much longer than step 3. If the build passes, Jenkins applies that status. If all statuses are 'success', the pull request is automatically merged.
What I observe:
Currently, my pull requests are merging feature branches to master. Master is protected (GitHub master branch: Settings>Branches>Protect this branch>Require status checks to pass before merging and the 'issue_opened' status check is set to Required.) Everything works as planned, except that the Github Pull Request Merger breaks GitHub convention and only respects its own status, not the other statuses.
So the PR merge depends only on Jenkins:
After step 3 POSTs a 'failure' status but before step 4 completes, GitHub reports that "Required statuses must pass before merging" and indicates that the 'issue_opened' status is 'failure'. But when the Jenkins build succeeds, the merge takes place anyway.
FWIW, the merge also happens if the feature branch already has a bad status at the time the pull request is created.
Any way I can get this to do what I want?
After more desperate fiddling I tried enabling the GH master branch protection setting Settings>Branches>Protected Branches>master>Protect this branch>Include administrators and 'voila': it pretty much works for me, more or less:
Jenkins Github Pull Request Merger still tries to do the merge, but GitHub returns this:
HTTP response code: 405, message: 'Method Not Allowed'.
As a result of the rc 405, Jenkins generates a java.io.IOException and regurgitates this json message from GH:
{"message":"2 of 2 required status checks have not succeeded: 1 failing and 1 pending.","documentation_url":"https://help.github.com/enterprise/2.10/user/articles/about-protected-branches"}
Jenkins then POSTS a 'failure' status (which one might quibble over because the build itself didn't fail).
This makes sense, since I am an admin for this repo, but I didn't anticipate that the Jenkins Github Pull Request Merger would not check the statuses. But I'm very pleased that this will get the job done for me, though from my point of view it would be cleaner if Jenkins first posted the build status, then POSTed the merge. Even better, if it checked the statuses it could simply skip the attempt to POST, and I wouldn't have had to enable the Include administrators protection. As it stands, I don't see a way to clear the Jenkins-posted failure status on the pull request. So we'll have to close such failed pull requests and create new ones.
Additional Info
Since posting initial answer I have discovered that one must not set/enable the GitHub Branch protections status check that comes from the Jenkins build. If it is not enabled, one can close the failed pull request, correct whatever problems caused other status checks or the Jenkins build to fail, and then start the pull request process over again by opening a new pull request.