We have two workflow that trigger on push set up like this:
on:
push:
branches:
- master
Inside of one workflow, it contains an action that push a bump version commit into master.
Inside of the other, it validate if the commit message is a bump and deploy automatically.
Currently, when we push a commit to master, we can see the github action created a commit in master like this:
Automated Version Bump ci: version bump to v1.2.3
Where Automated Version Bump is the name of the GitHub action and ci: version bump to v1.2.3 is the commit message generated by the GitHub action
I was expecting the workflow to trigger again because of the automated commit.
Does that means Automated Commit does not trigger workflow hook?
Thank you!
It seems this behaviour is a feature.
From the workflow events page:
An action in a workflow run can't trigger a new workflow run. For
example, if an action pushes code using the repository's GITHUB_TOKEN,
a new workflow will not run even when the repository contains a
workflow configured to run when push events occur.
So basically, events that originate from a workflow cannot trigger other workflows.
An alternative would be to use a scheduled workflow that checks every couple hours or so and does the validation.
on:
schedule:
- cron: '0 0/2 * * *'
Related
I have two branches i.e. main and develop. I want to run code with GitHub Actions for branch main (Production) and for develop (Staging) on schedule (nightly).
I've read that the workflow schedule can only be configured for the default branch on GitHub. So, what implementation for the workflow.yaml would be?
Yes, according to schedule:
Scheduled workflows run on the latest commit on the default or base branch.
However, it looks like it's doable by configuring the cron job for the default branch and then somehow triggering the workflow for the non-default branch e.g. using the GitHub API or CLI.
See workflow_dispatch for more details.
Or, via workflow_run configuration after completion of the workflow on the default branch. Though, in this case, you might not want to combine both in general scenarios.
In Azure Devops, I have a repo that's in Bitbucket. I'd like to trigger a package publish on every approved pr that gets merged to the develop branch.
I've figured out how to conditionally run a task if the build is a pr or not, and how to trigger if the pr is to develop, but that means that the task is run for every PR created to develop. I'd like the task to only run when the pr has been merged to develop.
I noticed the following variables in my pipeline:
SYSTEM_PULLREQUEST_ISFORK=False
SYSTEM_PULLREQUEST_MERGEDAT=
SYSTEM_PULLREQUEST_PULLREQUESTID=139
SYSTEM_PULLREQUEST_PULLREQUESTNUMBER=139
SYSTEM_PULLREQUEST_SOURCEBRANCH=source-branch
SYSTEM_PULLREQUEST_SOURCECOMMITID=e55835e7e2e65ad87fd09a03959fefcfcc4d475f
SYSTEM_PULLREQUEST_SOURCEREPOSITORYURI=[repoURL]
SYSTEM_PULLREQUEST_TARGETBRANCH=develop
And the SYSTEM_PULLREQUEST_MERGEDAT= variable stood out. Anyone have suggestions? Am I overly complicating this?
It is possible to achieve this with just conditions. Let's say you were merging from feature branch to develop branch. And you only want a task to be executed when the pr has been merged to develop.
First of all you should know the default CI triggers and PR triggers for Bitbucket repository on Azure pipeline.
1, CI triggers
If you don't specify any triggers, the default is as if you wrote below, which means commit to any branch will trigger the pipeline.
trigger:
branches:
include:
- '*'
When you specify a trigger, it replaces the default implicit trigger, and only pushes to branches that are explicitly configured to be included will trigger a pipeline. Includes are processed first, and then excludes are removed from that list.
2, PR triggers
If no pr triggers appear in your YAML file, pull request validations are automatically enabled for all branches.
When you specify a pr trigger, it replaces the default implicit pr trigger, and only pushes to branches that are explicitly configured to be included will trigger a pipeline.
Each new run builds the latest commit from the source branch of the pull request. This is different from how Azure Pipelines builds pull requests in other repositories (e.g., Azure Repos or GitHub), where it builds the merge commit,
See the document for more information.
So if you don't specify any CI triggers or PR Triggers. The default behavior is to enable the triggers for all branches. And the PR triggers will only trigger the pipeline to build the last commit from the source branch(ie. Feature branch) instead of develop branch.
So it will explain why there are two triggered builds on an update to a pr. one is CI trigger(ie. IndividualCI), another is PullRequest. Both builds were against the source branch (ie.feature).
When the pr was merged to develop. what happened was a new commit being added to develop branch, which will trigger the CI build. So the task you want to trigger should be run against develop branch.
As for above case of yours. I suggest you disable the pr triggers and only enable the CI triggers.(for pr triggers will only build the latest commit from the source branch, which is the same with CI trigger. )
You can disable the pr trigger like below:
pr: none
So you can just set the condition like below for the task
- task: taskname
input:
condition: and(eq(variables['Build.SourceBranchName'], 'develop'), eq(variables['Build.Reason'], 'IndividualCI'))
You can also use Webhook to trigger the azure pipeline. And set the condtion to eq(variables['Build.Reason'], 'ResourceTrigger')
resources:
webhooks:
- webhook: bitbucketwebhook
connection: bitbucketwebhook
Please see this thread for more information.
Currently, our team has limited GitHub actions in minutes, so I would only like to run GitHub actions when the WIP flag is not present.
Currently we use this plugin WIP to check if a branch is work in progress.
Is there a way that if the commit is flagged as WIP, that the GitHub actions to not trigger so we can conserve our monthly minutes allowance?
You should be able to use the pull_request event with the ready_for_review or even review_requested tags.
This example will only run when a pull request is marked ready for review.
on:
pull_request:
types: [ready_for_review]
Draft pull requests
Pull request trigger event
I'm setting up Github actions for a few of my projects.
The flow I'd like to achieve is:
A developer clicks on the "Merge pull request" button
A Github action testing workflow will take place
If the tests pass - The merge is executed
The reason for this kind of flow, is I wouldn't like the tests to run on each commit pushed to the branch. I want the flow to run only when trying to merge.
My question is:
Is there a way to manually execute a workflow only when trying / wanting to merge, and making sure the branch can be merged into master if and only if the tests have passed?
Unfortunately, there's no merged or merge_attempt activity type on the pull request event (yet). Even if there was, I don't believe GitHub has a way to block merges on the completion of a workflow (yet).
What I would suggest as a workaround here is to run your test 1. after the fact on pushes to the master branch, and 2. on pull_request events with certain activity types which indicate that the user is likely to attempt a merge soon. For example, ready_for_review or review_requested.
Something like this:
name: tests
on:
push:
branches:
- master
pull_request:
branches:
- master
types:
- ready_for_review
- review_requested
I want to use both CI-triggers and PR build validation in Azure DevOps. The goal is that as long as no PR has been created (and published) for a feature/topic-branch, the CI triggers should ensure that the branch gets built (so that developers get early feedback). I configured the following in the Pipeline (yaml):
trigger:
branches:
include:
- chore/*
- feature/*
- fix/*
- refactor/*
paths:
include:
- frontend/*
...
This works well. I further configured PR build validation under branch policies. The problem is that two builds are triggered now: the CI build and the PR build. Since we often update PRs multiple times to fix issues found during the code review, building everything twice isn't really what we need.
Is there any way to configure that CI builds are only triggered if there's no PR build for the same push?
This is not possible. They are totally separated triggers not aware of each other.
But you can achiever your result in a slightly different way. If you have branch policy configured and you sleect there a build you can set pr: none in you yaml definiton. It will block PR build, leaving CI build as they are. And this CI build will be considered as condition for you branch policy check.
Selecting this checkbox you will get list of builds which you may select as required
My Ci trigger build
PR view:
If I understand the question correctly add:
trigger: none
In your CI pipeline. This will have the PR kick it off via branch policy. Your CD pipeline will be triggered when the merge into master happens.
If you are using the Azure DevOps Repo, then the PR build is controlled by branch policies, but the CI-trigger (in azure-pipeline.yaml) has nothing to do with this branch policy.
So if you want both build validation for PR and the CI build at the same time, then every time you push your changes to update a PR, duplicate pipeline builds would be unavoidable. It is a side-effect.