I've set up a workflow in GitHub actions to run my tests and create an artifact of the test coverage. The stripped down version of my YAML file looks like this:
name: Build
on: [pull_request]
jobs:
build:
runs-on: ubuntu-latest
steps:
# Other steps here
- name: Build app
- name: Run tests
- name: Create artifact of test coverage
# Other steps here
The problem is that the artifact does not get created when the tests fail.
I figured out about if: always() condition the from the docs, but this will also cause this step to run when my Build app step fails. I don't want that to happen because there is nothing to archive in that case.
How can I only run this step if the previous step has run (either succeeded or failed)?
Try checking success() OR failure().
name: Build
on: [pull_request]
jobs:
build:
runs-on: ubuntu-latest
steps:
# Other steps here
- name: Build app
- name: Run tests
- name: Create artifact of test coverage
if: success() || failure()
# Other steps here
Alternatively, create a step output of the exit code that you can check in later steps. For example:
- name: Build app
id: build
run: |
<build command>
echo ::set-output name=exit_code::$?
- name: Run tests
- name: Create artifact of test coverage
if: steps.build.outputs.exit_code == 0
A possible better alternative is <step>.outcome or <step>.conclusion
https://docs.github.com/en/actions/learn-github-actions/contexts#steps-context
steps.<step id>.conclusion. The result of a completed step after continue-on-error is applied. Possible values are success, failure, cancelled, or skipped. When a continue-on-error step fails, the outcome is failure, but the final conclusion is success.
steps.<step id>.outcome The result of a completed step before continue-on-error is applied. Possible values are success, failure, cancelled, or skipped. When a continue-on-error step fails, the outcome is failure, but the final conclusion is success.
- name: Build app
id: build
run: |
<build command>
- name: Run tests
- name: Create artifact of test coverage
if: steps.build.outcome == 'success'
Related
We have a few status checks added but due to the amount of time it takes to run 1 job, i would like to only have it run when specific files are changed.
I can update the job via the paths: aka:
on:
pull_request:
paths:
- '**.tf'
but then we have to over right the merge request.
Is it possible to have a job that has to run for status checks but ONLY under a condition without having to do a manual intervention / override?
You could use the action dorny/paths-filter to create edited file filters and then run the intensive task as a conditional step in the job. This means the required status check will still run but just skip a step.
on:
pull_request:
jobs:
bigjob:
name: Some Big Job
runs-on: ubuntu-latest
steps:
- name: Check for Modified TF Files
uses: dorny/paths-filter#v2.2.1
id: filter
with:
filters: |
tf:
- '**/*.tf'
# Only run step if files found
- name: Run Task
if: steps.filter.outputs.tf== 'true'
shell: bash
run: echo "some task"
If we were to use minimal resources, doing these steps would look something like:
setup --- checkout, install fixed versions via cache
then trigger in parallel 1 command to run:
lint
test
e2e
all in parallel.
Unfortunately, with the current options I've found out there, the best scenario I can find is to have a separate workflow file for lint, test, e2e that are called by a main workflow and upon success build an artifact.
The issue with this is.
checkout will run 3 times.
install command will run 3 times.
Which can be mitigated with caching, but you're still looking at 10-15 seconds extra per job for those steps.
Is there a way to optimise this and still keep the reusable steps?
Even if I would keep everything in 1 giant file, I'd still define the lint, test, e2e steps as separate jobs and not as 1 single step part of a job.
Can we call a 'workflow' and run it in the same environment on the spot somehow?
This example calls checkout and caches the repo using the $ {{ github.run_id }} to prevent the cache conflicting with other runs. The cache is then used by the child workflows in place of checking out. e2e, test and lint will wait for the cache to be created and then all run in parallel.
Depending on your use case it may be excessive to create a new cache for each run_id, you can adjust this as you need. If speed is what you're after I'd also suggest only caching the files that you need for your child workflows, and not take everything like I've done in the example below.
name: main_caller
on: workflow_dispatch
jobs:
cache_checkout:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v3
- uses: actions/upload-artifact#v3
with:
name: my-checkout-${{ github.run_id }}
path: ${{ github.workspace }}/**/*
run_lint:
needs: cache_checkout
uses: ./.github/workflows/lint.yml
run_test:
needs: cache_checkout
uses: ./.github/workflows/test.yml
./.github/workflows/lint.yml example: (e2e and test will follow this pattern)
name: lint
on: workflow_call
jobs:
lint:
runs-on: ubuntu-latest
steps:
- name: Get Cached Checkout
uses: actions/download-artifact#v3
with:
name: my-checkout-${{ github.run_id }}
- name: Do linting things
run: echo "I'm linting!"
Edited as per comments - all jobs in GitHub run in parallel, but to have cleaner example you could use matrix strategy. To make it work you need it to depend on a 'setup' job that will install everything and create the artifacts (this is done using the needs keyword).
In the following example the install job would setup everything and then the example job, which uses matrix strategy, will run the lint/test/e2e flow in separate parallel jobs after it downloads the required artifacts.
jobs:
install:
runs-on: ubuntu-latest
- uses: actions/checkout#v3
- name: Compile artifacts
run: *install fixed versions/create artifacts*
- uses: actions/upload-artifact#v3
with:
name: my-artifact
path: path/to/my_artifact
example:
runs-on: ubuntu-latest
needs: install
strategy:
matrix:
action: [lint, test, e2e]
steps:
- uses: actions/download-artifact#v3
with:
name: my-artifact
path: path/to/artifact
- name: lint
if: ${{ matrix.lint }}
run: echo "lint"
- name: test
if: ${{ matrix.test }}
run: echo "test"
- name: e2e
if: ${{ matrix.e2e }}
run: echo "e2e"
It will create a workflow like this:
This is the workflow I'm currently using on GitHub
name: Windows10 - CI
on: [ push ]
jobs:
run-test:
runs-on: [ self-hosted, windows, DO ]
steps:
- uses: actions/checkout#v2
with:
clean: false
- name: Run nds2 CI - Sanity Test
if: github.ref == 'refs/heads/master'
run: cd c:\actions-runner\_work\nds2\nds2 ; python3 ci_host.py --master
- name: Run nds2 CI - Build Installer
if: github.ref != 'refs/heads/master'
run: cd c:\actions-runner\_work\nds2\nds2 ; python3 ci_host.py
I have a windows 10 computer which listens for an incoming job by using the GitHub runner.
Upon an incoming job, if a push is being made to the master branch the script ci_host.py is being run with the '--master' flag which spins up a VM and runs multiple tests on it. Eventually, at the end of the tests, the script restores the VM to a pre-configured snap shot.
So basically what I'm trying to achieve is, when the job is being canceled through the GitHub actions web interface then the script which handles the test is being canceled mid-job and doesn't have the chance to restore the VM to its prior clean state (snapshot).
How can I run a script which will be run at the end of the workflow even if the job was canceled?
So no matter what happens my VM could be restored to its clean state
Thanks in advance for your help :)
You can use Job status check functions to execute a step depending on what happened on the job before it (or not):
success: Returns true when none of the previous steps have failed or been canceled.
always: Always returns true, even when canceled. A job or step will not run when a critical failure prevents the task from running. For example, if getting sources failed.
cancelled: Returns true if the workflow was canceled.
failure: Returns true when any previous step of a job fails.
Example of use:
steps:
...
- name: Execute if the job succeeded
if: ${{ success() }}
- name: Execute if the job failed
if: ${{ failure() }}
- name: Execute if the job was cancelled
if: ${{ cancelled() }}
- name: Always execute
if: ${{ always() }}
Using Github Actions for some CI/CD.
Currently I am experiencing strange behavior where my jobs are being skipped despite the conditions being met. deploy-api has two conditions, if code was pushed to master and test-api was a success. But even though we are meeting those conditions, it is still being skipped.
jobs:
test-api:
name: Run tests on API
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v1
- name: Get dependencies
run: npm install
working-directory: ./api
- name: Run tests
run: npm run test
working-directory: ./api
deploy-api:
needs: test-api # other job must finish
if: github.ref == 'refs/heads/master' && needs.test-api.status == 'success' #only run if it's a commit to master AND previous success
As seen in the picture the second job is being skipped despite the push being on the master branch (as seen on the top) AND the previous job being successful.
Am I missing something in the code? Does anyone know of a workaround that can be used?
It would be nice if the UI told the user why it was skipped!
Use needs.test-api.result == 'success' (there is no .status) in the if expression.
See https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#needs-context.
I'm trying to follow an example Github has for testing my build with github actions, and then compressing the test results and uploading them as an artifact.
https://help.github.com/en/actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts#uploading-build-and-test-artifacts
I'm having trouble with what to do when my tests fail though. This is my action. When my tests pass everything works great, my results are zipped an exported as an artifact, but if my tests fail, it stops the rest of the steps in the job, so my results never get published.
I tried adding the continue-on-error: true https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepscontinue-on-error
This makes it continue after it fails and uploads my test results. but then the job is marked as passed, even though my test step failed. Is there some way to have it upload my artifact even if a step fails, while still marking the overall job as failed?
name: CI
on:
pull_request:
branches:
- master
push:
branches:
- master
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v1
- name: Test App
run: ./gradlew test
- name: Archive Rest Results
uses: actions/upload-artifact#v1
with:
name: test-results
path: app/build/reports/tests
You can add
if: always()
to your step to have it run even if a previous step fails
https://docs.github.com/en/actions/learn-github-actions/expressions#status-check-functions
so for a single step it would look like this:
steps:
- name: Build App
run: ./build.sh
- name: Archive Test Results
if: always()
uses: actions/upload-artifact#v1
with:
name: test-results
path: app/build
Or you can add it to a job:
jobs:
job1:
job2:
needs: job1
job3:
if: always()
needs: [job1, job2]
Additionally, as pointed out below, putting always() will cause the function to run even if the build is canceled.
If dont want the function to run when you manually cancel a job, you can instead put:
if: success() || failure()
Other way, you can add continue-on-error: true.
Look like
- name: Job fail
continue-on-error: true
run |
exit 1
- name: Next job
run |
echo Hello
Read more in here.
run a github-actions step, even if the previous step fails
If you only need to execute the step if it succeeds or fails, then:
steps:
- name: Build App
run: ./build.sh
- name: Archive Test Results
if: success() || failure()
uses: actions/upload-artifact#v1
with:
name: test-results
path: app/build
Why use success() || failure() instead of always()?
Reading the Status check functions documentation on Github:
always
Causes the step to always execute, and returns true, even when canceled. A job or step will not run when a critical failure prevents the task from running. For example, if getting sources failed.
Which means the job will run even when it gets cancelled, if that's what you want, then go ahead. Otherwise, success() || failure() would be more suitable.
Note -
The documentation made clear thanks to Vladimir Panteleev in which he submitted the following PR: Github Docs PR #8411
Addon: if you have following sitution. 2 steps i.e. build > deploy and in some cases i.e. workflow_dispatch with input parameters you might want to skip build and proceed with deploy. At the same time you might want deploy to be skipped, when build failed.
Logically that would be something like skipped or not failed as deploy conditional.
if: always() will not work, cause it will always trigger deploy, even if build failed.
Solution is pretty simple:
if: ${{ !failure() }}
Mind that you cannot skip brackets when negating in if:, cause it reports syntax error.
The other answers here are great and work, but you might want a little more granularity.
For instance, ./upload only if ./test ran, even if it failed.
However, if something else failed and prevented the tests from running, don't upload.
# ... Other steps
- run: ./test
id: test
- run: ./upload
if: success() || steps.test.conclusion == 'failure'
steps.*.conclusion will be success, failure, cancelled, or skipped.
success or failure indicate the step ran. cancelled or skipped means it didn't.
Note there is an important caveat that you must test at least one success() or failure() in if.
if: steps.test.conclusion == 'success' || steps.test.conclusion == 'failure' won't work as expected.
you can add || true to your command.
example:
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v1
- name: Test App
run: ./gradlew test || true