I'm using github environments in my github workflow. I want to read the environment name in a step of a job.
According to this documentation. It seems that the job context does not have that information. Is it any other way to achieve this?
Basically this is what i want to achieve:
jobs:
deployment:
name: Deploy to dev
environment: dev
runs-on: ubuntu-latest
steps:
- run: echo ${{ job.environment.name }}
# Expected to print 'dev'
you should use: jobs.<job_id>.environment.
See in docs: https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment
Related
I currently have a GitHub Action that triggers on:
pull_request_review:
types: [submitted]
I then want to run a command, which expects the contents of changes of the Pull Request.
Previously, I was using
on:
push
and I had no issues with the contents of the files being available in the Action context.
However, my command is failing now, and I think it's because the context only includes the commit that the action was triggered on (no file changes.)
Previously I was running this action on push and that was always successful, with the file changes being available in the context.
I'm using:
steps:
- uses: actions/checkout#v2
(https://github.com/actions/checkout)
Is it possible to use this to have all the file changes on the Pull Request within the Action context?
Any help on this would be appreciated!
You can do that by using an open source Action available on marketplace:
jobs:
build:
runs-on: ubuntu-latest # windows-latest | macos-latest
name: Test changed-files
steps:
- uses: actions/checkout#v2
with:
fetch-depth: 0 # OR "2" -> To retrieve the preceding commit.
- name: Get changed files
id: changed-files
uses: tj-actions/changed-files#v14.6
- name: List all changed files
run: |
for file in ${{ steps.changed-files.outputs.all_changed_files }}; do
echo "$file was changed"
done
The solution above uses git checkout and git diff to get files changed by PR. Alternatively if you really need just information about paths changed and you don't really need files themselves (no checkout) - you can do it without checkout using gh CLI:
gh pr view XXX --json files -q '.files[].path'
You can run it like this:
jobs:
comment:
runs-on: ubuntu-latest
steps:
- run: gh pr view XXX --json files -q '.files[].path'
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
I'm trying to organize my workflow artifacts (on a self-hosted runner) using a structure similar to this:
c:\github\artifacts\{org}\{repo}\{runid}
Different organizations in our enterprise COULD have a repository with the same name, so I wanted to be able to organize by organization name.
I have this so far:
c:\github\artifacts\{org}\{${{ github.event.repository.name }}\${{ github.run_id }}\
How can I determine the organization name?
You can get that from github context. Here are few that might be of use:
${{ github.repository }}
${{ github.repository_owner }}
If you don't know what are the values and which env variables are available to runner, you can just run env in a step to print it out, like so:
name: Print environment variables
on:
workflow_dispatch:
jobs:
debug:
runs-on: ubuntu-latest
steps:
- name: Print
run: env | sort
I have a simple workflow:
name: Test CI
env:
path_to_watch_for_commits: 'testdir/testfile'
on:
push:
branches:
- master
paths:
- ${{ env.path_to_watch_for_commits }}
workflow_dispatch:
jobs:
build:
runs-on: ubuntu
steps:
- uses: actions/checkout#v2
I want to use variable path_to_watch_for_commits in paths. But this syntax is wrong. Also i try ${{ path_to_watch_for_commits }} and $path_to_watch_for_commits with no results. What am i doing wrong?
There is a Naming conventions for environment variables explaining that:
Any new environment variables you set that point to a location on the filesystem should have a _PATH suffix. The HOME and GITHUB_WORKSPACE default variables are exceptions to this convention because the words "home" and "workspace" already imply a location.
Regarding the use of environment variables at different levels inside the workflow, here is an example with WORKFLOW, JOB and STEP variables:
name: Example
on: [push, workflow_dispatch]
env:
WORKFLOW_VARIABLE: WORKFLOW
jobs:
test:
runs-on: ubuntu-latest
env:
JOB_VARIABLE: JOB
steps:
- name: Run Commands with various variables
if: ${{ env.WORKFLOW_VARIABLE == 'WORKFLOW' }}
env:
STEP_VARIABLE: STEP
run: |
echo "Hello World"
echo "This is the $WORKFLOW_VARIABLE environment variable"
echo "This is the $JOB_VARIABLE environment variable"
echo "This is the $STEP_VARIABLE environment variable"
Regarding the possibility of the behaviour you want to achieve in your workflow, you can't set variables at the workflow and use them as paths on the same level, because:
Variables are substituted in the runner operating system after the job
is sent to the runner.
Reference
A workaround could be to trigger the workflow every time on push event, using the paths-filter action with an if conditional to execute specific steps if it match your paths.
It's not the best solution regarding optimisation, but it will work.
I recently hooked up my project with github actions for continuous integration. I created two separate jobs: the first one checks if the code in the pull request is accepted by our linter, and the second one checks if the code passes the test suite. I like that having two jobs like this shows up as two separate checkmarks in the Github webpage for the pull request:
The problem I'm having now is that there is some duplicated code in workflow YAML file: the first 3 steps, which install Lua and Luarocks. Not only is it annoying to maintain, but it also wastes CI minutes by running the same actions twice. Is there a way to avoid this? So that the setup code is only written in one place, and only runs once when the workflow executes?
But I am confused what would be the proper way to proceed:
Should I create my own Github Action with the shared setup code?
Should I create a Docker image that already has Lua and Luarocks pre-installed?
Should I use a single job? Can I still have independent checkmarks for the linter and the test suite if they are steps of the same job?
Something else?
Here is the current YAML file for my workflow:
name: Github Actions CI
on: [ pull_request ]
jobs:
lint:
name: Lint
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- uses: leafo/gh-actions-lua#v8.0.0
- uses: leafo/gh-actions-luarocks#v4.0.0
- run: luarocks install luacheck
- run: ./run-linter.sh
test:
name: Test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- uses: leafo/gh-actions-lua#v8.0.0
- uses: leafo/gh-actions-luarocks#v4.0.0
- run: luarocks install busted
- run: ./build-project.sh
- run: ./run-test-suite.sh
I tried searching for similar questions but couldn't find anything that exactly answered my question:
Caching APT packages in GitHub Actions workflow: I can't use this solution because I don't have a way to precisely specify all the versions of all the dependencies that I am using, so that they may be cached. I also don't mind if separate runs of the workflow are not cached. I'm more worried about the code duplication.
Github actions share workspace/artifacts between jobs? I don't want to have to manage uploading uploading artifacts to a separate service and then deleting them afterwards.
Reuse portion of github action across jobs: In that question the only difference between the jobs is a single variable, so accepted answer is to use a build matrix. But I don't think a build matrix would work as well in my case, where only the setup code is the same?
As of today (August 2021) composite action is no longer limited to run. GitHub Actions: Reduce duplication with action composition
name: "Publish to Docker"
description: "Pushes built artifacts to Docker"
inputs:
registry_username:
description: “Username for image registry”
required: true
registry_password:
description: “Password for image registry”
required: true
runs:
using: "composite"
steps:
- uses: docker/setup-buildx-action#v1
- uses: docker/login-action#v1
with:
username: ${{inputs.registry_username}}
password: ${{inputs.registry_password}}
- uses: docker/build-push-action#v2
with:
context: .
push: true
tags: user/app:latest
Old Answer
What you are looking for is composite action which help you reuse once defined set of steps.
jobs:
lint:
name: Lint
runs-on: ubuntu-latest
steps:
- uses: octocat/say-hello#v1
- run: luarocks install luacheck
- run: ./run-linter.sh
test:
name: Test
runs-on: ubuntu-latest
steps:
- uses: octocat/say-hello#v1
- run: luarocks install busted
- run: ./build-project.sh
- run: ./run-test-suite.sh
octocat/say-hello/action.yml:
runs:
using: "composite"
steps:
- run: echo "Nice to meet you!"
shell: pwsh
For more details you can also check's ADR here.
And why you can't simply run it once for all jobs, because each job may run on a different machine.
A job is a set of steps that execute on the same runner. By default, a workflow with multiple jobs will run those jobs in parallel. You can also configure a workflow to run jobs sequentially. For example, a workflow can have two sequential jobs that build and test code, where the test job is dependent on the status of the build job. If the build job fails, the test job will not run.
There are 3 main approaches for code reusing in GitHub Actions:
Reusable Workflows
Dispatched workflows
Composite Actions
There is an article describing their pros and cons.
In your case if the duplicated steps are in the single workflow you also can:
extract them to the "preparation" job
upload build artifacts
add "preparation" job to "needs" key of both jobs
download build artifact in both jobs
The below code snippet should do the work for you. Instead of creating two jobs, one for lint and another for test, you can use one job and create multiple tasks
name: Github Actions CI
on: [ pull_request ]
jobs:
lint:
name: Lint and Test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- uses: leafo/gh-actions-lua#v8.0.0
- uses: leafo/gh-actions-luarocks#v4.0.0
- name: Install Luacheck
run: luarocks install luacheck
- name: Run Lint Check
- run: ./run-linter.sh
- name: Install Busted
run: luarocks install busted
- name: Build Project
run: ./build-project.sh
- name: Run Test Suite
- run: ./run-test-suite.sh
As I have repetitve steps in my Github Actions, I would like to create a template. Let's make a example
name: ci
on: ["push"]
jobs:
build-and-test:
strategy:
matrix:
os: [ubuntu-latest]
runs-on: ${{ matrix.os }}
steps:
- name: checkout
uses: actions/checkout#v1
- name: do stuff
run: |
bash stuff
Is it possible to save only the steps in a separated file? And import afterwards?
Unfortunately it does not look like github-actions supports reusing workflows. Not even YAML anchors are supported.
It looks like the only way to share steps (not setup) is to create actions.
Update: A storm brewing
I have also caught wind of the possibility of reusing actions. Follow the issue to stay up-to-date.
I mentioned in "Reuse portion of GitHub action across jobs" that reusing GitHub Worfflow is now (Oct. 2021) available.
The documentation "Reusing workflows" includes a section "Reusable workflows and workflow templates", which leads to "Creating workflow templates"
If you need to refer to a repository's default branch, you can use the $default-branch placeholder.
When a workflow is created using your template, the placeholder will be automatically replaced with the name of the repository's default branch.
For example, this file named octo-organization-ci.yml demonstrates a basic workflow.
name: Octo Organization CI
on:
push:
branches: [ $default-branch ]
pull_request:
branches: [ $default-branch ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- name: Run a one-line script
run: echo Hello from Octo Organization