Given the following quite standard workflow:
name: Test
on: [push, pull_request]
jobs:
test:
strategy:
fail-fast: false
matrix:
os: [ubuntu-latest]
ruby: [3.0, 3.1]
runs-on: ${{ matrix.os }}
steps:
- name: Check out
uses: actions/checkout#v2
- name: Set up Ruby ${{ matrix.ruby }}
uses: ruby/setup-ruby#v1
with:
ruby-version: ${{ matrix.ruby }}
bundler-cache: true
- name: Run tests
run: SPEC_SCOPE=all bundle exec rake
The separate runs of test according to the matrix are labelled like so:
For the sake of better understanding, can the way the matrix is labelled be changed from "ubuntu-latest, 3.1" to something like "ubuntu-latest, ruby-3.1"?
#dhannanjay answered this on Github
You can change the name for a job by providing a name property. You can access all the metadata in the job configuration.
name: Run tests
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [12.x, 13.x]
mongodb-version: [4.0, 4.2]
name: Node.js ${{ matrix.node-version }} - MongoDB ${{ matrix.mongodb-version }}
steps:
- name: …
(source: https://futurestud.io/tutorials/github-actions-customize-the-job-name)
Related
Currently I am trying to have 1 job scanning SonarQube and 1 job checking for the quality gate in github actions. In order to get the report from gradle of the quality check in the second job, I have to cache it (or atleast with the limited knowledge I have). But I don't want when I rerun the workflow on the same PR or on different PRs use the same cache, since the report is only valid for a current workflow and not futher ones (those need to always create a new report and give the new report to the second job).
Here is my workflow:
name: SonarQube
on:
push:
branches:
- master # or the name of your main branch
pull_request:
types: [opened, synchronize, reopened]
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v3
with:
fetch-depth: 0 # Shallow clones should be disabled for a better relevancy of analysis
- name: Set up JDK 11
uses: actions/setup-java#v3
with:
java-version: 11
distribution: corretto
cache: gradle
- name: Build and analyze
env:
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
run: ./gradlew --info sonar -Dsonar.host.url=$SONAR_HOST_URL -Dsonar.login=$SONAR_TOKEN
- name: Cache report
uses: actions/cache#v3
with:
path: build/sonar/
key: report-task
qualityCheck:
needs: scan
runs-on: ubuntu-latest
steps:
- name: Get cache report
uses: actions/cache#v3
with:
path: build/sonar/
key: report-task
- name: Quality Gate check
id: sonarqube-quality-gate-check
uses: sonarsource/sonarqube-quality-gate-action#master
# Force to fail step after specific time.
timeout-minutes: 5
with:
scanMetadataReportFile: build/sonar/report-task.txt
env:
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
What needs to be changed to achieve this?
I have currently done this:
- name: Cache report
uses: actions/cache#v3
with:
path: build/sonar/
key: commit-${{ github.sha }}-workflow-${{ github.run_id }}-${{ github.run_number }}-report-task-${{ hashFiles('build/sonar/**') }}
This doesn't solve the problem that it keeps the cache after the workflow ends, but it now won't use the report of previous workflows.
I've been trying to follow the example provided by SonarCloud to set it up, but it doesn't work.
name: SonarCloud
on:
push:
branches:
- master
pull_request:
types: [opened, synchronize, reopened]
jobs:
build:
name: Build and analyze
runs-on: macos-latest
env:
BUILD_WRAPPER_OUT_DIR: build_wrapper_output_directory # Directory where build-wrapper output will be placed
steps:
- uses: actions/checkout#v3
with:
fetch-depth: 0 # Shallow clones should be disabled for a better relevancy of analysis
- name: Install sonar-scanner and build-wrapper
uses: SonarSource/sonarcloud-github-c-cpp#v1
- name: Run build-wrapper
run: |
build-wrapper-macosx-x86 --out-dir ${{ env.BUILD_WRAPPER_OUT_DIR }}<insert_your_clean_build_command>
- name: Run sonar-scanner
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
run: |
sonar-scanner --define sonar.cfamily.build-wrapper-output="${{ env.BUILD_WRAPPER_OUT_DIR }}"
It always goes wrong in the Run build-wrapper-macosx-x86 production process.
Is there enough solution or sample code to guide me?
I have a github actions workflow like this:
name: Print test type
on: [push]
jobs:
build:
strategy:
fail-fast: false
matrix:
test_type: ['test-alpha', 'test-beta']
os: [ubuntu-latest]
python-version: ['3.7', '3.9']
include:
- os: windows-latest
python-version: '3.8'
runs-on: ${{ matrix.os }}
steps:
- name: Print Alpha
if: ${{ matrix.test_type == 'test-alpha'}}
run: echo "test type is alpha. the os name is ${{ runner.os }}"
- name: Print Beta
if: ${{ matrix.test_type == 'test-beta'}}
run: echo "test type is beta. the os name is ${{ runner.os }}"
When I run this workflow, the windows CI starts and completes but it is not showing any output. In particular, the if statements are not getting executed. Am I missing some point here? Because when I include the test-type in matrix, I expect to also see windows X py3.8 X {alpha, beta} combination in workflow.
In the ubuntu CI, it works fine - getting executed for all combinations in the matrix (ubuntu X {py3.7,py3.9} X {alpha,beta}.)
The include method does not work here because Github tries to extend the already existing run configurations. If this does not work (which is the case here), then a new configuration is created for each include. (For more information: https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs#expanding-or-adding-matrix-configurations)
In your case, however, the new created configurations do not contain a specified test-type. Now there are two possibilities. Either add the test-type manually:
name: Print test type
on: [push]
jobs:
build:
strategy:
fail-fast: false
matrix:
test_type: ['test-alpha', 'test-beta']
os: [ubuntu-latest]
python-version: ['3.7', '3.9']
include:
- os: windows-latest
python-version: '3.8'
test_type: 'test-alpha'
- os: windows-latest
python-version: '3.8'
test_type: 'test-beta'
runs-on: ${{ matrix.os }}
steps:
- name: Print Alpha
if: ${{ matrix.test_type == 'test-alpha'}}
run: echo "test type is alpha. the os name is ${{ runner.os }}"
- name: Print Beta
if: ${{ matrix.test_type == 'test-beta'}}
run: echo "test type is beta. the os name is ${{ runner.os }}"
or remove the unwanted combinations:
name: Print test type
on: [push]
jobs:
build:
strategy:
fail-fast: false
matrix:
test_type: ['test-alpha', 'test-beta']
os: [ubuntu-latest, windows-latest]
python-version: ['3.7', '3.8', '3.9']
exclude:
- os: windows-latest
python-version: '3.7'
- os: windows-latest
python-version: '3.9'
- os: ubuntu-latest
python-version: '3.8'
runs-on: ${{ matrix.os }}
steps:
- name: Print Alpha
if: ${{ matrix.test_type == 'test-alpha'}}
run: echo "test type is alpha. the os name is ${{ runner.os }}"
- name: Print Beta
if: ${{ matrix.test_type == 'test-beta'}}
run: echo "test type is beta. the os name is ${{ runner.os }}"
I have the following two actions, how can I make the second action be executed at the end of the first after making the first one commit and push?
Action1
on:
workflow_dispatch:
inputs:
name: Scrape Data
jobs:
build:
name: Build
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#master
- name: Build
run: npm install
- name: Scrape
run: npm run action
- uses: mikeal/publish-to-github-action#master
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # GitHub sets this for you
Action2
on:
workflow_dispatch:
inputs:
name: Visit Data
jobs:
build:
name: Build
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#master
- name: Build
run: npm install
- name: Scrape
run: npm run visit
- uses: mikeal/publish-to-github-action#master
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # GitHub sets this for you
You could use the workflow_run trigger on the second workflow.
Example:
name: Visit Data
on:
workflow_run:
workflows: ['Scrape Data'] # First workflow name
types:
- completed # can also use 'requested'
jobs:
build:
name: Build
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#master
- name: Build
run: npm install
- name: Scrape
run: npm run visit
- uses: mikeal/publish-to-github-action#master
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Note that you can't use workflow inputs in that case (I observed you had it set, and if it's necessary you would need to use another trigger, for example through the Github API using a workflow dispatch event with a payload).
The workflow in file inrisk.packages.ci.yml generates a tag and a realise of the code when a push is done in the develop branch. The below works as expected.
name: Code Int
on:
push:
paths:
- 'infra/**'
jobs:
ci:
runs-on: ubuntu-latest
steps:
# Checks-out to $GITHUB_WORKSPACE
- uses: actions/checkout#v2
- name: Basic Checks
run: |
whoami
ls -lah
pwd
- uses: actions/setup-node#v1
# Create a new release when on develop which triggers the deployment
- name: Bump version and push tag
if: github.ref == 'refs/heads/develop'
uses: mathieudutour/github-tag-action#v4.5
id: tag_version
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- name: Create Release
if: github.ref == 'refs/heads/develop'
id: create_release
uses: actions/create-release#v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
tag_name: ${{ steps.tag_version.outputs.new_tag }}
release_name: Release ${{ steps.tag_version.outputs.new_tag }}
draft: false
prerelease: false
The below workflow in file inrisk.packages.cd.yml and is suppose to be triggered when ever a tag/realise is created/published.
name: Code Deploy
on:
push:
tags:
- 'v*'
release:
types:
- published
- created
- released
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
# Checks-out to $GITHUB_WORKSPACE
- uses: actions/checkout#v2
- uses: actions/setup-node#v1
- name: Install Yarn
run: npm install -g yarn
- uses: chrislennon/action-aws-cli#v1.1
- name: Install, Build and Deploy
run: |
whoami
ls -lah
pwd
The second workflow Code Deploy dose not get trigger after Code Int publishes/created a tag/realise
However when I manually create a realise/tag the second workflow Code Deploy get triggered
This seems to be by design as stated here .This is to stop recursive workflow runs.
I used this article to get around the problem