I'm trying to create a GitHub workflow that will run ONLY when a new branch is created with a pattern. The purpose of this is to create a Code Review Pull Request when a new branch is pushed to origin, but only on the first time the branch is created, so using a push event will not work and why I'm looking at create.
All of these combinations fail where any new branch created will run, instead of those just matching the pattern
name: "Create Code Review PR"
on:
create:
branches: ['feature/**']
or
name: "Create Code Reivew PR"
on:
create:
branches:
- 'feature/**'
- 'support/**'
- 'hotfix/**'
In both of these scenarios, if push a new branch called no-code-review, the above workflow will still run, but my expected behavior is that it wont run, but it should when a new branch such as these: feature/new-branch, support/new-support-branch or hotfix/fix-this ONLY.
The create event does not support a branch filter.
The alternative would be using an if condition on your step or job:
if: ${{ contains(github.ref, 'refs/heads/releases/') }}
Here's more information: https://github.community/t/trigger-job-on-branch-created/16878/5
Related
I need github workflow to be triggered only when there is a change in files in .github/workflows/*. It shouldn't trigger the workflow if the there is a change in any other files.
For e.g., if I make change in the Docker file, the workflow shouldn't trigger.
My branch looks like this:
My workflow yaml look like this
on:
#[push]
pull_request:
branches:
- test
types:
- closed
#paths-ignore:
# - '.github/*'
paths:
- '.github/*'
The above yaml is not working for what I desire.
The issue here is that the workflow trigger configurations (the on field) doesn't exactly work as you expect.
According to the official documentation:
If you specify multiple events, only one of those events needs to occur to trigger your workflow. If multiple triggering events for your workflow occur at the same time, multiple workflow runs will be triggered.
Therefore, in your case, each subtype in the pull_request event is considered as a separate event, and would trigger the workflow even if the conditions of the other subtypes aren't met.
What is happening here, is that any PR to the test branch triggers the pull_request: branches: - test subtype, independently of the paths: - '.github/*' configuration (it won't matter which file you update if the branch is test).
Moreover, with those configurations, the workflow would also trigger if you updated the '.github/*' path when opening a PR from another branch.
Summarizing, with your current configurations:
open PR from branch test: the workflow will trigger.
open PR from a branch which is not test: the workflow will trigger only if there are changes in the path is '.github/*'
close any PR: the workflow will trigger.
If you want the workflow to trigger only when there are changes to the specific path, when opening a PR, you should use:
on:
pull_request:
paths:
- '.github/workflows/*'
(Without configuring any other event.)
Now, if you want the workflow to trigger each time there is a push to a branch (when you open OR update a PR for example), you should use:
on:
push:
paths:
- '.github/workflows/*'
I'm trying to reduce the amount of files I have for my workflows from 4 to 1. And with that my on is like this:
on:
pull_request:
types: [opened, synchronize, closed]
push:
branches: [master]
I know it's possible to use if in workflows but looking at the documentation I didn't find which parameters I should use to trigger the correct jobs when:
Pull request is opened
Pull request is closed
Push is made to a existing pull request
Push is made to a brach
The piece of documentation that touches on how to use if is this one.
You can use it at the job level. Consider the following example to execute a job only when the PR has been closed and merged (not just closed):
name: Build Your App
on:
pull_request:
types: [ closed ]
jobs:
build:
# this job will only run if the PR has been merged, not just 'closed'
if: github.event.pull_request.merged == true
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout#v2
with:
fetch-depth: '0'
And you can also use it at the step level, to execute or not the step based on the {{ expression }} evaluation, as the documentation shows.
Based on your ask, I would use the information on the github.event.* payload. To do that I use to re-create the conditions and triggers on a test repository and print it to the console. Then I know what I have to look for in each kind of event. It's like debugging the events. This is the documentation to do that.
I have two workflows, the first one runs a build script and generates an artifact.
The first one is triggered when a pull request is created like this:
name: build
on:
pull_request:
types: [opened, edited, ready_for_review, reopened]
The second flow runs when the first is done, by using the workflow_runtrigger like this:
on:
workflow_run:
workflows: ["build"]
types:
- "completed"
The second flow has to be separate and run after the first one. When done it is supposed to post a comment on the PR that triggered the first workflow, but I am unable to find out how.
According to the Github Action Docs this is one of the typical use cases, as per this qoute:
For example, if your pull_request workflow generates build artifacts, you can create
a new workflow that uses workflow_run to analyze the results and add a comment to the
original pull request.
But I can't seem to find out how. I can get the first workflow's id in the 2nd workflow's context.payload.workflow_run.id, but workflow_run should also have about the pull request, but they`re empty.
What am I doing wrong, and where can I find the necessary info to be able to comment on my created pull request?
You're not doing anything wrong, it's just that the Pull Request datas from the first workflow are not present in the Github Context of the second workflow.
To resolve your problem, you could send the Pull Request datas you need from the first workflow to the second workflow.
There are different ways to do it, for example using a dispatch event (instead of a workflow run), or an artifact.
For the artifact, it would look like something as below:
In the FIRST workflow, you get the PR number from the github.event. Then you save that number into a file and upload it as an artifact.
- name: Save the PR number in an artifact
shell: bash
env:
PULL_REQUEST_NUMBER: ${{ github.event.number }}
run: echo $PULL_REQUEST_NUMBER > pull_request_number.txt
- name: Upload the PULL REQUEST number
uses: actions/upload-artifact#v2
with:
name: pull_request_number
path: ./pull_request_number.txt
In the SECOND workflow, you get the artifact and the Pull Request number from the FIRST workflow, using the following GitHub Apps:
- name: Download workflow artifact
uses: dawidd6/action-download-artifact#v2.11.0
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
workflow: <first_workflow_name>.yml
run_id: ${{ github.event.workflow_run.id }}
- name: Read the pull_request_number.txt file
id: pull_request_number_reader
uses: juliangruber/read-file-action#v1.0.0
with:
path: ./pull_request_number/pull_request_number.txt
- name: Step to add comment on PR
[...]
I have a set of GitHub Actions configured to block pull requests from being merged until the Actions complete successfully. However, every time a new commit is pushed to a PR, the Actions are run again, which can be very wasteful if the author is not yet ready to merge, and intends to make future changes. Is there any way to have a GitHub Action still block a PR being merged but also not run the Action automatically?
With this recent update you can now convert pull requests back to draft status. So you could do that when you need to make changes and disable the CI for drafts. Then convert the draft to a pull request after the changes are complete to rerun CI.
on: pull_request
jobs:
build:
if: github.event.pull_request.draft == 'false'
runs-on: ubuntu-latest
steps:
...
One workaroound would be for the Action to look for a specific comment (for example: "[TO MERGE]: this commit is about ...), and:
return immediately if '[TO MERGE]' is not found, minimizing the action overhead on each commit
go on with checks, if '[TO MERGE]' is found.
I'm trying to enforce labelling PR's using enforce-label-action.
name: Enforce PR label
on:
pull_request:
types: [labeled, unlabeled, opened, edited]
jobs:
enforce-label:
runs-on: ubuntu-latest
steps:
- uses: yogevbd/enforce-label-action#master
with:
REQUIRED_LABELS_ANY: "bug,enhancement,feature"
The problem is that each time PR is labeled, a new check-run getting created and the old one's still having a failing status which cause the check-suite to show: Some checks were not successful.
Is it possible for github-actions to discard the old check-runs when a workflow check with the same name is getting triggered?
This is now fixed, it was a bug on GitHubs end.