I have made a pull request on GitHub for a workflow that should be invoked in the following event:
on:
pull_request_review:
types: [submitted,edited]
Despite the fact that no pull request review has been done yet, it seems the workflow did create a status check in the PR that adds the particular file.
Why is that?
Shouldn't the workflow be executed only when a PR review is submitted?
Related
I am using bitbucket and jenkins as my CI/CD solution.
I am running a sanity job everytime Pull request is raised. I want to send email notification on the success or failure of the job to the owner of the pull requuest. The challenge I am facing is I am not able to get the user information for the PR in jenkins pipeline.
Anybody has solved this porblem ?
Here's a different approach to this: instead of directly emailing the author of the PR, use the Bitbucket API to write a comment on the PR (doc). Since you would already have the PR ID, it's just a matter of sending a POST request.
By default, any comments written on a Bitbucket PR automatically trigger an email to the PR author + PR reviewers so they will be getting notified via email as well.
I'm looking on a way to trigger a Azure pipeline ONLY on successful (or attempted) pull request merge.
Now I have :
trigger:
branches:
include:
- DEV
steps:
- script: FOO
But this runs EVERY time there is a change on the DEV branch and I would like to avoid that.
Besides, I want a programmatic response not going trough the UI each time.
EDIT:
A weird thing is happnening
condition: and(succeeded(), eq(variables['Build.Reason'], 'PullRequest'))
gets:
Expanded: and(True, eq('IndividualCI', 'PullRequest'))"
When doing a PR, and thus doesn't work as intented
I'm looking on a way to trigger a Azure pipeline ONLY on successful (or attempted) pull request merge.
There is no such out of box way to achieve this at this moment.
We could only set the CI trigger on the target branch, but we could set the condotion for the pipeline to avoid build any task:
and(succeeded(), eq(variables['Build.Reason'], 'PullRequest'))
For example:
trigger:
branches:
include:
- DEV
steps:
- script: FOO
condition: and(succeeded(), eq(variables['Build.Reason'], 'PullRequest'))
Or you could set the condition for the stage, job and so on.
Please check the document Specify conditions for some more details.
If there is a change on the DEV branch and it would be avoided by the condition.
Note: With above way, the pipeline will be triggered, but no task will be executed.
And if you even do not want the pipeline be triggered. You could add new pipeline with powershall task to invoke REST API to trigger above pipeline and set the condition to the powershell task.
In this way, the pipeline will only triggered when the commit comes from the PR.
Update:
Doing a PR on the DEV branch results in : "Expanded: and(True,
eq('IndividualCI', 'PullRequest'))"
Yes,you are correct. That because azure devops does not have the feature to trigger the pipeline after the PR completed. Pull request trigger and Build Validation both trigger the pipeline when the PR starts.
To resolve this request, we could try create a service hook to monitor PR status. If the PR status changes, the pipeline is triggered through API or Application, you could check this document for some more details.
And another way to achieve is using the REST API.
The main idea is：
create a pipeline and set it as Build validation, but not set it as Required, should set it as Optional:
Add powershell task in above pipeline to invoke REST API to monitor the PR status until it complated, and add another task to invoke the REST API to trigger your current pipeline.
So, you could remove the:
trigger:
branches:
include:
- DEV
in your current pipeline.
The trigger you have set is a CI trigger, it will work whenever the target branch has a new commit.
Currently, there isn't a trigger that works when a pull request is completed.
The feature closest to your needs is PR triggers and build validation branch policy.
They will work when a pull request is created or when it has been changed.
If you are using Azure Repos Git, please use branch policy for build validation. If you are using GitHub or Bitbucket Could, please use pr triggers. Click the documents for the detailed information.
Besides, you can use branch policy to prevent the direct commits. When you set the branch policy of any type, only users with "Bypass policies" permission can commit to the branch directly. The rest of the users must commit the branch through a pull request.
How to create branch policy: Branch policies and settings.
How to set "Bypass policies" permission: Set Git repository permissions.
% gh workflow run test.yml
gives me:
could not create workflow dispatch event: HTTP 422: Workflow does not have 'workflow_dispatch' trigger (https://api.github.com/repos/bcpitutor/v2_lms/actions/workflows/20724896/dispatches)
Why do I need a workflow_dispatch trigger?
The gh workflow run man page does confirm:
The given workflow file must support a workflow_dispatch 'on' trigger in order to be run in this way.
It comes from cli/cli issue 1725, and issue 2889, implemented by PR 3303.
This PR implements gh workflow run, a command for creating workflow_dispatch events for workflows that support them
Again, a confirmation your workflow needs to support that workflow_dispatch trigger.
Let's say I have a pipeline my-pipeline which 1) Install dependencies 2) Test my application.
I set up a build validation policy which triggers my-pipeline upon creation of a pull request.
Once the pull request is approved and merged, my-pipeline is triggered again.
Questions
Is there a way to differentiate the creation of the PR and the merged of the PR within my yaml file, so I can use conditions to trigger some scripts on creation but not on merge. Something similar to condition: and(succeeded(), startsWith(variables['build.reason'], 'PullRequest'))
For instance, I would trigger test on PR creation but not after the merge
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.