This is the config.yml file I have created. It has 2 workflows. Smoke tests & cypress-all-tests
version: 2.1
orbs:
cypress: cypress-io/cypress#1
workflows:
pre-merge-run:
jobs:
- cypress/run:
name: Smoke tests
command: npm run cy:smoke
filters:
branches:
ignore:
-main
cypress-all-tests:
jobs:
- cypress/run:
name: All tests
command: npm run cy:all:tests
filters:
branches:
only:
- main
My intention is to run Smoke tests workflow on every pull request before it is merged to the main branch. Then run only cypress-all-tests workflow once the PR is merged to the main branch.
When the config file is run by CircleCI, this is what happens:
Only smoke tests run on the pull request before merge (which is what I want)
BUT
Both the workflows run after the PR is merged to the main branch (which is not what I need). Only the workflow cypress-all-tests should be running now.
I don't know where am I making the mistake.
So it was a silly mistake!
I just had to put a space between - and main. You can see the absence of a space in the screenshot below.
Related
I have a github actions workflow, which lints, builds, tests, releases and deploys the software: common CI/CD steps.
This being a FLOSS project, I want to run some jobs for pull-requests and some only when stuff is pushed to main (master) branch and/or tagged. The latter jobs release and deploy the software, so I want to avoid running those when someone makes a PR at all costs.
For the sake of this question details are omitted and all steps abstracted away in shell scripts. The workflow looks like this:
name: CI
on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
env:
CARGO_TERM_COLOR: always
TAG_FILE: "./job_tags.txt"
jobs:
lint:
runs-on: ubuntu-latest
steps:
- name: Lint
run: lint.sh
build:
runs-on: ubuntu-latest
steps:
- name: Build
run: build.sh
test:
needs: build
runs-on: ubuntu-latest
steps:
- name: Test
run: test.sh
deploy:
needs: [lint, test, build]
if: startsWith(github.ref, 'refs/tags')
runs-on: ubuntu-latest
steps:
- name: Deploy
run: deploy.sh
There are dependencies (needs:) and one if, witch tries to achieve the following:
For all pull_requests to main, run lint, build, test. but not deploy
For all tagged commits to main, run lint, build, test and deploy.
The things I cannot find in the documentation are:
What if someone branches off, creates commits, tags them and then makes a PR. Will that trigger the tags? Do I need extra protection in place to ensure the tag was made on main, of the repo that I hold, and not a fork?
How can I match this on tags with a pattern only? Say v*, only?
Is this feasible in one workflow file? Or should I split the "run for all PRs" and "run only for tagged commits to main" into separate workflows (I'd rather avoid this as it comes with either a lot of complexity -building own reusable actions- or duplication; since I cannot make a job needs: jobs from other workflows).
Is there a function or expression that I'm overlooking which does exactly what I want: filter if this is "my" repo or someone elses in a PR?
I have a GitHub workflow as below.
name: Releaser
on:
push:
tags:
- 'v*.*.*'
This workflow will be triggered when I manually push a new tag like v1.1.1-rc1. It works fine.
Now, I want to have another workflow to replace the "manually push".
name: sync-tags
on:
workflow_dispatch:
push:
paths:
- TAGS
jobs:
steps:
- name: foo-example
uses: foo-example
This workflow will be triggered when there's a change made in the TAGS directory. The jobs will create a new tag like v1.1.1-rc1. It works fine as well. But, after the v1.1.1-rc1 is created by the sync-tags, the Releaser is not triggered.
I was wondering why the Releaser can be triggered by manually pushing tags but can't be triggered by tagging from other workflows?
I am having this same problem. It turns out this is intentional behavior from GitHub Actions.
… if a workflow run 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.
Explicitly invoking the release workflow works! (Note: this needs GITHUB_TOKEN in the environment, which I happen to do for the entire workflow.)
- name: New tag & launch release process
run: |
echo "Tagging $new_tag"
git tag $new_tag
git push --tags
# Explicitly run our release workflow for this new tag
gh workflow run release.yml --ref $new_tag
My release workflow needed to be enhanced to allow manual runs. The workflow_dispatch: line in the on: section.
on:
push:
tags:
- 'v*.*.*'
workflow_dispatch:
To make sure we're building a release on a tag, I added if: github.ref_type == 'tag' to each job within the release workflow.
I'd like a Github action to run on Pull Request to a specific base branch, but from another specific head branch.
name: Run production tests
on:
push:
pull_request:
branches:
- main
jobs: ...
However, I specifically want something like this to run when a branch called develop is PR'd against main, not just every time something is PR'd to main.
Is such a workflow possible? I might be missing it, but I don't see a way to target head branches in the docs.
From the documentation, I could not find any filters for the head branch. But this is doable with if conditions for jobs.
For example
name: Run production tests
on:
pull_request:
branches:
- main
jobs:
build:
if: ${{ github.head_ref == 'develop'}}
runs-on: ubuntu-latest
steps:
- name: Run a multi-line script
run: |
echo "Do something here"
We have a YAML based pipeline that Unit Tests and build an ASP NET Core website then if everything is OK it deploys to DEV, TEST and eventually Live Azure Resources.
Our source control is Git within Azure Dev Ops.
Our process has us working in a branch for each feature, once those branches are ready we merge them into a "release" branch for an integration test before being PR'ed to MAIN. An example of our release branch would be "release_3_1_5".
The start of the YAML pipeline looks like this
pool:
vmImage: 'windows-latest'
# Why would I want 'resources'
# resources:
# pipelines:
# - pipeline:
variables:
azureSubscriptionEndpoint: 'ARM Service Connection'
webAppKind: webApp
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
# Change this when adding functionality that is a breaking change
majorVersion: 3
# Change this when adding functionality that is backwards compatible
minorVersion: 1
# Change this when making fixes that are backwards compatible and not adding functionality
buildVersion: 0
# Concatenate version parts and buildId to get a full build version string
fullBuildVersionString: $(majorVersion).$(minorVersion).$(buildVersion).$(Build.BuildID)
name: $(MajorVersion).$(MinorVersion).$(buildVersion).$(Build.BuildID)
stages:
- stage: Build
jobs:
- job: Build_Job
steps:
- bash: |
echo $(fullBuildVersionString)
We don't specify any explicit triggers so the build runs everytime we push to a branch.
The "MAIN" branch has some branch policies set, those policies include "Build Validation" and currently the Build Validation build policy is configured to run the same YAML pipeline.
The CI pipeline works just fine when pushing changes to our branches, except when the branch in question is the subject\source of a PR to MAIN. In this situation the pipeline starts twice. Once for the push to the "release" branch and once by the branch policy because of the PR into MAIN.
Is there a better way to configure the pipeline so it does not kick off twice? I basically do not want the CI truigger to fire when the branch is the source of a PR to MAIN but that looks like an impossible condition
This is something we struggle with as well. We have just accepted the double builds for now. However, I am starting to consider not having a build trigger for feature/ branches and only trigger for PRs.
The only other option are double manifests. One manifest for branches that are not MAIN, and the other being a manifest that includes only PRs and the MAIN branch.
If you want builds to run for branches, you could consider pre-receive hooks that requires builds to run locally.
I'm currently using the "git-flow" branching model outlined here. Following that model, once I've completed work on a feature branch, I'd like to add new GitHub actions to that branch (for example, to run my feaure's automated tests) before the branch is merged.
Following the branching model, I don't want to define the actions in a workflow file on the default branch before that feature branch is merged into it. Ideally I want to add the actions on the feature branch itself before the merge, but this doesn't appear to work.
I've added the below sample workflow to my feature branch, but GitHub does not detect it. Am I missing something here, or can workflows only detected and run once they're on the default branch? If the latter is true, do people generally merge their branches, then add workflows for them?
# Name workflow
name: Test workflow
# Read only permissions
permissions: read-all
# Triggered once every 15 minutes
on:
workflow_dispatch:
schedule:
- cron: '15 * * * *'
# Listing of jobs to be run
jobs:
# Just output the Python version for now.
python-tests:
name: Python Tests
runs-on: ubuntu-latest
# Use the environment configured with secrets
environment: python-test-environment
# Set the working directory?
defaults:
run:
working-directory: tests
steps:
# Checkout the repository
- name: Checkout
uses: actions/checkout#v2
ref: 'dev-tests'
# Configure Python
- name: Set up Python 3.7
uses: actions/setup-python#v2
with:
python-version: 3.7
# Output the Python version
- name: Display version
run: python -c "import sys; print(sys.version)"
Update: I can see now that the "schedule" trigger only works on the default branch. However, removing it and just using the workflow_dispatch trigger still (on the feature branch YML file) still does not show the workflow on GitHub.