Is it possible to split a GitHub Actions workflow file and reference it from other? I need to deploy an application into multiple environments i.e. staging and production and would like to share half of the steps to minimize maintenance.
You can split each action in the following file format:
folder named "test-action"
.github/test-action/action.yml
with contents
name: test-action
description: test action
inputs:
test_input:
description: key
required: true
runs:
using: composite
steps:
- name: echo test
shell: bash
run: |
echo ${{inputs.test_input}}
then you can refer to the action from any yml:
- name: test-action
uses: ./.github/test-action
with:
test_input: "test-string-value"
the key here was to make sure that the file within your named action folder would be called "action.yml"
It seems like there is no way as CircleCI allows defining commands that are a set of steps: https://github.community/t5/GitHub-Actions/reusing-sharing-inheriting-steps-between-jobs-declarations/td-p/37849
At this moment, I guess we can use repository_dispatch as a workaround.
In this example, it handles events between repositories, but I think we can apply this in same repository: https://blog.marcnuri.com/triggering-github-actions-across-different-repositories/
Related
Does anyone know what this does ?
uses: ./
I see it used in quite a few places but cannot seem to find any reference for it.
The uses keyword of github actions is used to specify the action that should be executed as part of a workflow. The ./ value tells GitHub to use the action defined in the current repository, rather than referencing a pre-built action.
It's also possible to specify the path to the action within the repository, rather than using ./. For example:
steps:
- uses: ./path
with:
parameter1: value1
parameter2: value2
This would execute the action located at ./path within the repository.
I can't for the life of me figure out why my GitHub Action isn't triggering on push. For context: I have a data file that is updated daily and pushed to the test branch with a timestamp commit message. I am trying to use this timestamp in a Dynamic Badge for my README. Everything works fine when the workflow is run manually (except, of course, I don't get the event data I am hoping to obtain when the action runs on the trigger.)
on:
push:
branches:
- test
paths:
- 'data/Sales.csv'
env:
BADGE_MESSAGE: ${{ github.event.commits[0].message }}
jobs:
create-badge-test:
runs-on: ubuntu-latest
steps:
- name: Create Dynamic Badge
uses: schneegans/dynamic-badges-action#v1.1.0
with:
auth: ${{ secrets.GIST_PAT }}
gistID: 0123456789 #Not actual gist ID
filename: test.json
label: Last Refresh
message: $BADGE_MESSAGE
color: orange
And yes, I've tried putting the branch name in quotes and updating the paths: to - '**.csv' and the action still does not trigger.
There must be something else wrong - all you have here in this workflows is just fine.
You can see it working here:
https://github.com/grzegorzkrukowski/stackoverflow_tests/actions/runs/1860382530
For this commit:
https://github.com/grzegorzkrukowski/stackoverflow_tests/commit/f3f8dd20fa780746441c7b6623b6a2a9929aa70d
It's exact copy of workflow from your question.
I would expect you are pushing a file with different name - keep in mind some systems will be case-sensitive - so pushing data/sales.csv won't work properly.
Another idea is that you pushing it to wrong branch or you have wrong path to the file.
You have to push to test branch and with data/Sales.csv - it only triggers workflow if both are true.
Short answers is - workflow is fine as it is - no brackets needed.
I could help more seeing the repository with this workflow and exact commits being done.
The action is not running because you also need to satisfy the paths condition as explained on GitHub docs
Note: If you use both the branches filter and the paths filter, the workflow will only run when both filters are satisfied.
If you want the action to run when you push to test you have to remove the paths condition
on:
push:
branches:
- 'test'
The following shows what the Github Actions tab displays for a typical build:
The Build step actually has a number of sub-steps, but I do not want to use Github Actions as a scripting language just to be able to have each sub-step discreetly displayed. Is there any sort of magic that Github Actions provides to signal that you wish the visualization of the build to show a discrete step (i.e. a "dynamic step")?
I'm hoping for something like the following which would cause the creation of discrete result nodes in the output of the Github Actions build visualization:
- name: Dynamic Steps
run |
echo "###github-action-step: Step 1"
echo "###github-action-step: Step 2"
echo "###github-action-step: Step 3"
Something close to that can be achieved by skipping steps and/or dynamically setting the steps name.
i.e. I'm using like this to customize the tab message on GH actions:
- name: "Pulling existing Docker image ${{ github.event.repository.name }}:${{ steps.variables.outputs.commitSha }}"
if: steps.image_checker.outputs.shouldBuildNewImage == 0
run: |
docker pull ${{ steps.variables.outputs.dockerRepositoryUrl }}:${{ steps.variables.outputs.commitSha }}
When the step is skipped, it still appears in the logs, but grayed out and in my scenario, the text doesn't show the 'image:tag' getting pulled
I want to build a GitHub Action that triggers on Pull Request (PR) Approval, but only when the PR contains modification to a particular path.
Currently, I have the following implementation:
on:
pull_request_review:
types: [submitted]
paths: ['mypath/**']
jobs:
build:
runs-on: self-hosted
steps:
- uses: actions/checkout#v2
- name: job name
if: github.event.review.state == 'approved'
[Reference: https://github.community/t/github-actions-manual-trigger-approvals]
However, the build job triggers on Approval, and seems to ignore the path. The build runs on any Approval regardless of what files have been modified in the PR.
Is it possible to trigger a GitHub Action only when a PR modifies a particular path and it is approved?
I know fuzzi found an alternative using another solution with labels, but here is my contribution if someone wants to resolve the question issue keeping the original premisses:
Context
The ON trigger conditions work as OR and not as AND. Therefore, in the question sample, the workflow will trigger when a pull_request_review is submitted OR when one of the updated file(s) path is the one informed.
Workaround
It's not possible to check both condition (yet?) through the on workflow level field alone.
Therefore, if you want to check both conditions, you would have to do it separately.
A solution could be to check the submitted PR in the ON trigger first, then checking the folder path in a job step.
Example
Here is an example of what the solution suggested above looks like using the paths-changes-filter action:
on:
pull_request_review:
types: [submitted]
jobs:
build:
runs-on: self-hosted #or any other runner
steps:
- uses: actions/checkout#v2
- uses: dorny/paths-filter#v2
id: changes
with:
filters: |
mypath:
- 'mypath/**'
# run only if some file in 'src' folder was changed
- if: steps.changes.outputs.mypath == 'true' && github.event.review.state == 'approved'
run: ...
I found a solution to this using GitHub Labels instead, rather than file paths.
I implemented a GitHub Action for automatically adding a Label to the PR, based on the updated file paths.
(https://github.com/actions/labeler)
I then modified my existing GH Action to check the Label value. My condition is now:
if: github.event.label.name == 'project' && github.event.review.state == 'approved'
Is there any way that a step in a workflow job can specify sub-steps to pass to a custom action?
steps:
- uses: ...
with:
steps:
- ...
- ...
- ...
For example, a uses: actions/cache#v2 will attempt to download a snapshot immediately (in the current step), and also inserts a post step to upload a fresh snapshot after all other steps in the parent job. This works well for build processes that (through multiple stages) intelligently recognise which objects need to be recreated and which do not. But it is not suited for workflows that need to set up a clean environment (or generate test data) that may then be manipulated by the tests. I'd like to make a different cache action, that is explicitly passed instructions for how to regenerate the cache from scratch, and which uploads the state before returning to the following step of the parent action.
Is there any way this could be achieved? (Composite actions? Advanced yaml syntax? Template expressions? Low-level actions toolkits/features? Implementing an interpreter to re-parse the input parameter?)