Our team recently switched to GitHub, and we set up some CICD flows using GitHub Actions. Now we have the problem, that certain actions are showing up in the wrong workflow lists.
If you check the below screenshot, you can see...
The currently selected workflow is Release CI
On the right hand side we can see the triggered actions...
But some of these actions actually concern a different workflow, namely Release 1.1. CI (marekd yellow) - which also has it's own entry in the workflow list on the left (marked green).
There is yet another kind of actions showing up (Release 1.1 PR CI), which also have their own workflow in the UI.
--> How comes? Am I misunderstanding the UI here?
In case this is important...
This is the start of the Release CI config:
name: Release CI
on:
push:
tags:
- 'release'
This is the start of the Release 1.1. CI config:
name: Release 1.1 CI
on:
push:
branches: [release_1_1]
This is the start of the Release 1.1 PR CI config:
name: Release 1.1 PR CI
on:
pull_request:
branches: [release_1_1]
Related
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.
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 have deployment action in my GitHub workflow.
I want to restrict this action trigger to the master branch only.
Here is a piece of workflow config:
on:
release:
branches:
- master
types:
- released
But when I'm publishing pre-release for any branch in my project it hits workflow immediately.
What's wrong with it? Please advice.
Tnx!
I have this github action that I think is wrong and didn't run for tags.
name: CI
on:
push:
branches:
- master
- /^v[0-9]+\.[0-9]+\.[0-9]+$/
I think that should be:
name: CI
on:
push:
branches:
- master
tags:
- v.*
My question is, after I update this ci config, how can I re-run this CI so that it runs on the tags? Or should I create a new tag just because I want this CI to run on it (I think this sounds bad since it means I created another release/tag without any actual updates, only CI config)?
Any help would be greatly appreciated!
Since July 2020, you could add a workflow_dispatch event and trigger manually your GitHub ACtion
(the workflow must exist on the default branch for the "Run workflow" button to appear)
That way, you can try and see if it does run based on your new tag criteria.
I'd like to push the build status automatically from Azure Devops to the github repository, so that pull requests can check for a build success before they can be merged.
I realise this can be done writing some custom code and calling the github status api, but there is a checkbox for it in the edit pipeline stage. It doesn't seem to work with Github though. See this image .
Other build tools like Bamboo have an out of the box plugin for doing this.
You need to define branch policy. You can read about this on my blog. You need to selected existing pipeline here in GitHub settings:
and then when you make PR you will get this:
You need to correctly define trigger options in your yaml file. For isntance:
this will run for all non master branch (with each commit pushed to GitHub pipeline will run)
for each merge to master will trigger pipeline too
trigger:
branches:
include:
- '*'
exclude:
- master
pr:
branches:
include:
- master
paths:
include:
- gated-checkin/*
exclude:
- gated-checkin/azure-pipelines.yml