I have a repository where status check and auto merge is enabled. I created a Pull Request using Rest API and want to enable auto merge so that the PR is merged once the status checks are passed. The problem is status checks kick off and pass as soon as I create the PR and I don't get enough time to enable auto merge on the PR using GraphQL API. Is there a way to overcome this?
Please Note: I'm using GitHub Enterprise and we don't have GitHub actions
Related
I'm creating a GitHub pull request using the appropriate REST API. Specifying a single assignee or an assignees (using either the user login or GitHub's internal id) has no effect. The pull request will be created, but without an assignee set. There also seems to be no other endpoint to explicitly assign a pull request to a user. Now I'm wondering whether it's possible at all to set the assignee of a pull request using the REST API?
Every pull request is an issue, but not every issue is a pull request.
For this reason, "shared" actions for both features, like manipulating
assignees, labels and milestones, are provided within the Issues API.
From PR Doc
So, you can use Add assignees to an issue API to set an assignee(s) to a pull request After PR is created. You need to know its number, which is in the JSON body of Create Pull Request's response.
/repos/{owner}/{repo}/issues/{issue_number}/assignees
where issue_number is same as pr_number
I have a branch policy that enforces the use of pull requests into a specific branch.
The policy also requires that an external status check is passed, in this case a web hook is triggered by the creation or update of the pull request. The web hook calls a web api which updates the status of the pull request via the devops REST API to set the required state check to succeeded or failed and include a description.
The description posted to the devops REST API is then displayed in the pull request in the event of a filed status check. For example:
I have control of the content of the returned description from the web api endpoint, and I am looking for a way to control the formatting of the displayed message in the pull request. Specifically a way to break the text over multiple lines.
I have tried adding a <br/> (shown above) or \n or \r or even \r\n to the text, all with no success.
Is it possible to do this? is there any parsing of the returned text, maybe to allow the use of something like markdown?
I have one action that sets the deployment status to success which in turn should trigger another action but that does not seem to work. Isn’t it possible to listen for deployment_status changes in one action that are triggered from within another action?
By design, an action in a workflow run can’t trigger a new workflow run with the default GitHub token. Please refer to the official doc for more details.
Creating personal access token as secrets instead is the workaround.
I am attempting to use the Azure DevOps Services REST API to set the PR Completion Options to enforce a squash merge on a Pull Request.
Note: I can't set a branch policy to enforce a squash merge as I am testing certain conditions to see if a squash merge is required or not and attempting to enforce a squash as if the branch policy is set for that PR only.
When I make the following call:
PATCH https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/pullrequests/{pullRequestId}?api-version=5.0
{
"completionOptions": {
"squashMerge": true
}
}
The response shows the value is set
Yet when attempting to complete the request, I would expect the "Squash changes when merging" checkbox to be ticked and disabled.
If I leave the form as-is and complete the merge, no squash is performed.
If I set bypassPolicy to true, I still see no difference in completion options.
So in summary, I know that the call is successful as the response is coming back with the options set, but the changes don't seem to be coming through to the Pull Request in Azure DevOps.
You could use a policy that enforces this.
If you go to branches in DevOps, select your branch -> policies you can allow only squash merges:
This should make all pull requests into the branch bound by the policy to be done using squash merge.
Here's how it works for Set auto-complete:
Microsoft responded in the developer community forums with the following answer.
In this case there is a difference between expected behavior in the UI
and via the REST endpoint. Setting squashMerge in completion options
tells the PR to complete with a squash only if you complete it with
the REST endpoint. In the user interface we respect user settings to
enable users to choose what they would like to do (if there is no
policy enabled). In this case, you did not enable a policy so a user
can either squash or not. The users preference actually supersedes
what you do with the REST API. If they squash merged the previous PR
we will remember this and create the same default for them on the next
PR.
TLDR: You cannot necessarily control the form default values with
the REST endpoint and should use policy to enforce squash merge (or
expect your users can set the checkbox or not depending on their
preference, but we do not force a default).
It doesn't work that way for me.
Branch Policy vs what is seen when clicking auto-complete
Is it possible to create a Github Check for pull requests? I know there are WebHooks, but is there a way to also hook into the UI?
Aim:
Pull Request made. Perform validation and update pull request if valid.
Pull Request merged. Create web call to URL. Update Github issue with confirmation.
What's the best way to do this? Is it only via Web Hooks, API calls and getting write oAuth credentials?
Note: you now (August 2018) officially have the notion of Checks
When checks are set up in a repository, pull requests have a Checks tab where you can view detailed build output from status checks and rerun failed checks.
I know there are WebHooks, but is there a way to also hook into the UI?
The recommended way of doing this is to use required status checks and the Status API, in combination with webhooks:
https://help.github.com/articles/about-required-status-checks/
https://developer.github.com/v3/repos/statuses/
Users set up required status checks on the repository so that merging a pull request is blocked if a specific status isn't success.
At the same time, webhooks trigger an external process when a pull request is updated, and that process creates statuses based on the output of that process. If the process completes successfully, then the process should create a success status which will be shown in the UI and unblock the merging of the pull request.
Is it only via Web Hooks, API calls and getting write oAuth credentials?
In order to create statuses, you will indeed need to authenticate with the credentials of a user that has push access to the repository (e.g. via a token from that user with the right scopes).