I am trying to automate applying label to the GitHub PRs.
I came across this awesome GitHub Action I am not able to understand on where to put labels and any[] or all[]
This is what I have tried so far -
# This workflow will triage pull requests and apply a label based on the
# paths that are modified in the pull request.
#
# To use this workflow, you will need to set up a .github/labeler.yml
# file with configuration. For more information, see:
# https://github.com/actions/labeler
name: Labeler
on: [pull_request]
jobs:
label:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
steps:
- uses: actions/labeler#v2
with:
repo-token: "${{ secrets.GITHUB_TOKEN }}"
sync-labels: true
- name: Applying labels.
deployment:
- any: ['deployment/backend-stack/deployment.yaml']
You can find some aspirations with this commit, basically the labeler config is in .github/labeler.yml.
As described in the official documentation you need to have two files in your .github/ folder:
actual workflow is defined in .github/workflows/labeler.yml
configuration is set in .github/labeler.yml
Difference of the key words any and all:
any: match ALL globs against ANY changed path
all: match ALL globs against ALL changed paths
Example
.github/workflows/labeler.yml
name: Labeler
on: [pull_request]
jobs:
label:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
steps:
- uses: actions/labeler#v2
with:
repo-token: "${{ secrets.GITHUB_TOKEN }}"
sync-labels: true
.github/labeler.yml
deployment:
- any: ['deployment/backend-stack/deployment.yaml']
Related
I am making a custom terraform provider for my organization.
I was following the instructions here:
https://www.terraform.io/registry/providers/publishing?_ga=2.233394398.119722977.1642457969-242172196.1631994131
In the section where it mentions to set up a GitHub Action by copying over the following into my workflows directory:
GitHub Actions workflow from the terraform-provider-scaffolding repository (https://github.com/hashicorp/terraform-provider-scaffolding/blob/main/.github/workflows/release.yml)
Unfortunately doing so seems to have caused the release workflow to no longer work and run. As a result, I was hoping I might get some overall insights into this as I am trying to hook it up to terraform registry and it's not letting me publish it because of a mal-release configuration.
Here is the repo:
https://github.com/Richard-Barrett/terraform-provider-mirantis
Here is the code that I am using for release.yml in my existing workflows:
# This GitHub action can publish assets for release when a tag is created.
# Currently its setup to run on any tag that matches the pattern "v*" (ie. v0.1.0).
#
# This uses an action (hashicorp/ghaction-import-gpg) that assumes you set your
# private key in the `GPG_PRIVATE_KEY` secret and passphrase in the `PASSPHRASE`
# secret. If you would rather own your own GPG handling, please fork this action
# or use an alternative one for key handling.
#
# You will need to pass the `--batch` flag to `gpg` in your signing step
# in `goreleaser` to indicate this is being used in a non-interactive mode.
#
name: release
on:
push:
tags:
- 'v*'
jobs:
goreleaser:
runs-on: ubuntu-latest
steps:
-
name: Checkout
uses: actions/checkout#v2.4.0
-
name: Unshallow
run: git fetch --prune --unshallow
-
name: Set up Go
uses: actions/setup-go#v2
with:
go-version: 1.17
-
name: Import GPG key
id: import_gpg
uses: hashicorp/ghaction-import-gpg#v2.1.0
env:
# These secrets will need to be configured for the repository:
GPG_PRIVATE_KEY: ${{ secrets.GPG_PRIVATE_KEY }}
PASSPHRASE: ${{ secrets.PASSPHRASE }}
-
name: Run GoReleaser
uses: goreleaser/goreleaser-action#v2.8.0
with:
version: latest
args: release --rm-dist
env:
GPG_FINGERPRINT: ${{ steps.import_gpg.outputs.fingerprint }}
# GitHub sets this automatically
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
I think it may be the way I am auto-tagging in my repo as well, here is what I am using within my tag.yml:
name: 'tag'
on:
push:
branches:
- main
jobs:
tag:
runs-on: ubuntu-latest
steps:
- name: 'Checkout'
uses: actions/checkout#v2.4.0
- name: 'Tag'
uses: anothrNick/github-tag-action#1.36.0
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Also, the tag workflow wasn't working at first, but now is, but my release status is just showing no status
So after much chagrin and heartache, I found out why it wasn't working.
I didn't specify the Branch on which the action was to be triggered:
Answer:
https://github.com/Richard-Barrett/terraform-provider-mirantis/commit/62a1fb003aee118e133dd22ce79dd488798214e1
The overall change was adding that to the release.yml.
The tag.yml is fine.
As a result, here was the overall change:
name: 'release'
on:
push:
branches:
- main
tags:
- 'v*'
jobs:
And the final release file looked like this:
# This GitHub action can publish assets for release when a tag is created.
# Currently its setup to run on any tag that matches the pattern "v*" (ie. v0.1.0).
#
# This uses an action (hashicorp/ghaction-import-gpg) that assumes you set your
# private key in the `GPG_PRIVATE_KEY` secret and passphrase in the `PASSPHRASE`
# secret. If you would rather own your own GPG handling, please fork this action
# or use an alternative one for key handling.
#
# You will need to pass the `--batch` flag to `gpg` in your signing step
# in `goreleaser` to indicate this is being used in a non-interactive mode.
#
name: 'release'
on:
push:
branches:
- main
tags:
- 'v*'
jobs:
goreleaser:
runs-on: ubuntu-latest
steps:
-
name: Checkout
uses: actions/checkout#v2.4.0
-
name: Unshallow
run: git fetch --prune --unshallow
-
name: Set up Go
uses: actions/setup-go#v2
with:
go-version: 1.17
-
name: Import GPG key
id: import_gpg
uses: hashicorp/ghaction-import-gpg#v2.1.0
env:
# These secrets will need to be configured for the repository:
GPG_PRIVATE_KEY: ${{ secrets.GPG_PRIVATE_KEY }}
PASSPHRASE: ${{ secrets.PASSPHRASE }}
-
name: Run GoReleaser
uses: goreleaser/goreleaser-action#v2.8.0
with:
version: latest
args: release --rm-dist
env:
GPG_FINGERPRINT: ${{ steps.import_gpg.outputs.fingerprint }}
# GitHub sets this automatically
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
I want to trigger a Github workflow only if a code is pushed to a specific branch and if a tag exists, but my config (github workflow) does not work as expected:
name: Deployment
on:
push:
branches:
- feature/BRANCH-NAME
tags:
- *
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v1
- uses: actions/setup-node#v1
with:
node-version: '10.x'
- name: Install dependencies
run: |
npm install
- name: Lint & build
run: |
npm run build
The workflow is triggered even if a tag does not exist.
How could I fix this?
EDIT: This workaround seemed to have solved my problem at the time of writing but I cannot guarantee that it still works as expected.
Since I couldn't find a way to implement an AND condition (i.e. tagged AND on master), I used the following workaround:
name: Worflow demo
on:
push:
tags:
- v*
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v1
- name: Exit if not on master branch
if: endsWith(github.ref, 'master') == false
run: exit -1
- name: Next job ...
This will trigger if there is a tagged (e.g. tag v1.0.0) commit pushed:
on:
push:
tags:
- v*
The first step ('Exit if not on master branch') then checks if the current branch doesn't end with master and exits the workflow (the subsequent tests will not start):
- name: Exit if not on master branch
if: endsWith(github.ref, 'master') == false
run: exit -1
Hope this helps someone else as well.
can use release event and github.event.release.target_commitish to make only tags on 'my_branch' to trigger the build
name: workflow demo
on:
release:
types:
- published
jobs:
my_job:
runs-on: ubuntu-latest
steps:
- name: build only on my_branch tag
if: ${{ github.event_name == 'release' && github.event.release.target_commitish == 'my_branch'}}
run: "something"
To fix the multiple unintended runs I removed the "branches:" scalar and just include and !exclude tags that I want my workflow to run on.
Following runs on tagged releases, not on release candidates:
name: 'tagged-release'
on:
push:
tags:
- 'v[0-9]+.[0-9]+.[0-9]+'
- '!*-rc[0-9]+'
The accepted answer didn't seem to work for me, as pointed out by dilithiummatrix in the comments.
So I tried outputting the available values of the github object, which you can do by adding this in your workflow file to see what is available:
- name: Dump job github var
env:
GITHUB_VAR: ${{ toJson(github) }}
run: echo "$GITHUB_VAR"
From this I noticed that as Billy Clark also pointed out, that github.event.base_ref contains refs/heads/production. So this worked for me:
# Only release from prod branch
- name: Exit if not on production branch
if: endsWith(github.event.base_ref, 'production') == false
run: exit -1
You can so by writing the following YAML code.
Keep in mind that you have to put the branches-ignore so that the workflow is not activated when you create branches. The part where you check whether the tag is pushed to a specific branch is covered in the second part of the answer.
name: Deployment
on:
push:
tags:
- *
branches-ignore:
- '*'
You can check for the name of the branch with the following code; specifically for every step of the job you are trying to accomplish.
- name: job
env:
BRANCH_NAME: ${{ github.head_ref || github.ref_name }}
if: contains(env.BRANCH_NAME, <branch-name>)
then follow up with some more code you want the workflow to do.
I am attempting to use GitHub Actions for a complete pipeline, including automatic SemVer versioning (using tags) that I would then like to consume after building my Docker image to tag it with the current version. This is the action that I am using to bump the version, which should have a new_tag output but I cannot reference it, this is what I am trying:
jobs:
setup:
...
version:
needs: [setup]
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
with:
fetch-depth: '0'
- name: Bump version and push tag
uses: anothrNick/github-tag-action#1.26.0
id: autoversion
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
WITH_V: true
sonar:
...
anchore:
...
docker:
needs: [setup, version]
steps:
...
- name: Build and push
uses: docker/build-push-action#v2
with:
context: .
push: true
tags: ansfire/flaskql:${{ needs.version.autoversion.outputs.new_tag }}
From what I have read using the needs key is supposed to allow one job to access upstream jobs but I cannot get it to access this. Do I need an outputs key in the version stage? Thanks!
Look into this answer, you need to define the outputs in the job creating the outputs, i.e.
jobs:
version:
[...]
outputs:
new_tag: ${{ steps.autoversion.outputs.new_tag }}
docker:
[...] tags: ansfire/flakql:${{ needs.version.outputs.new_tag }}
I've already attempted to ask about this on the repo itself with no luck so far.
I've created a fairly simple workflow based on this SO answer to retrieve a forgotten secret:
name: Show Me the S3cr3tz
on: [push]
jobs:
debug:
name: Debug
runs-on: ubuntu-latest
steps:
- name: Check out code
uses: actions/checkout#v2
- name: Set up secret file
env:
MY_SECRET: ${{ secrets.MY_SECRET }}
run: |
echo $MY_SECRET >> secrets.txt
- name: Run tmate
uses: mxschmitt/action-tmate#v3
However, I can never see the tmate link because it is cancelled automatically and immediately after leaving the queue:
What am I doing wrong?
This is probably related to the recent GitHub Actions outage.
The workflow YAML syntax is valid, and confirmed to be working.
Here's a GitHub Actions workflow file for a Python project named spam:
name: PyInstaller
on:
[...]
jobs:
create_release:
[...]
make_artifact:
needs: create_release
strategy:
matrix:
os: [ ubuntu-latest, windows-latest ]
runs-on: ${{ matrix.os }}
env:
ARTIFACT_PATH: dist/spam.zip
ARTIFACT_NAME: spam-${{ runner.os }}.zip
steps:
[...]
When this runs, the workflow fails at startup with this:
The workflow is not valid. [...]:
Unrecognized named-value: 'runner'. Located at position 1 within expression: runner.os
I'm attempting to use the os attribute of the runner context. This SO Q&A mentions that the env context can only be used in specific places, so I suspect something similar is happening here. However, I can't find any official documentation addressing this.
Is there any way to reference the runner context to set an environment variable within the env clause of a job, as shown above?
I'm looking for a way to set the environment variable for all steps in the job, so an env inside a step item won't do.
The workaround I've got for now is to add a step specifically to set environment variables:
steps:
- name: Setup environment
run: |
echo "ARTIFACT_NAME=spam-${{ runner.os }}.zip" >> $GITHUB_ENV
however this only works on the Linux runner.
If you scroll down a bit further in the GitHub Actions docs you linked, there's an example workflow printing different contexts to the log.
- name: Dump runner context
env:
RUNNER_CONTEXT: ${{ toJson(runner) }}
I set up a test repo with a workflow demonstration:
on: push
jobs:
one:
runs-on: ${{ matrix.os }}
strategy:
matrix:
os:
- 'ubuntu-latest'
- 'windows-latest'
- 'macos-latest'
steps:
- name: Dump runner context
env:
RUNNER_CONTEXT: ${{ toJson(runner) }}
run: echo "$RUNNER_CONTEXT"
- name: Get runner OS
env:
RUNNER_OS: ${{ runner.os }}
run: echo "$RUNNER_OS"
- name: Create file with runner OS in name
env:
OS_FILENAME: 'spam-${{ runner.os }}.zip'
run: |
echo "OS_FILENAME=spam-${{ runner.os }}.zip" >> $GITHUB_ENV
touch "./${{ env.OS_FILENAME }}"
touch blah.txt
- name: List created file
run: ls -l "./${{ env.OS_FILENAME }}"
It looks like you can also set and access env in steps, and those persist across workflow steps. For example, I set the environment variable $OS_FILENAME in step 3 using the echo syntax, and reference it in step 4. This works across all the OS options offered on GitHub Actions.
Note that the GitHub Actions docs state that "Environment variables must be explicitly referenced using the env context in expression syntax or through use of the $GITHUB_ENV file directly; environment variables are not implicitly available in shell commands.". Basically, it means you can't implicitly refer to env variables like $FOO and instead must refer to them as ${{ env.FOO }} in shell commands.
So for your scenario, does it satisfy your requirements if you set $ARTIFACT_NAME in the first step of the job? I wonder if the reason might be that the runner context isn't created until the first step - I'm not sure I have a way of testing this.