Does GitHub action support nested templates? For example, here is an example of Azure Pipeline yaml where it calls another yaml file:
- job: BuildFunctions
steps:
- ${{ each func in parameters.functionApps }}:
- template: yaml/build-functionapps.yml
parameters:
Is it possible to call a yaml file from another yaml file in GitHub actions?
You can use composite run steps actions. These are actions that are solely defined in YAML (documentation).
You can now specify containers, other composite actions (up to a depth of 9) and node actions in additional to the previously available run steps
node actions likely refers to leaf actions, i.e. actions that don't call any other actions.
Source: https://github.com/actions/runner/issues/646#issuecomment-901336347
Workflow
[...]
jobs:
job:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- uses: ./.github/workflows/composite-action
[...]
Composite run steps action
.github/workflows/composite-action/action.yml (same repository as the workflow)
name: "My composite action"
description: "Checks out the repository and does something"
runs:
using: "composite"
steps:
- uses: actions/checkout#v2
- uses: actions/setup-node#v2
with:
node-version: 12
- run: npm test
shell: bash
- run: |
echo "Executing action"
shell: bash
Old limitations:
What does composite run steps currently support?
For each run step in a composite action, we support:
name
id
run
env
shell
working-directory
In addition, we support mapping input and outputs throughout the action.
See docs for more info.
What does Composite Run Steps Not Support
We don't support setting conditionals, continue-on-error, timeout-minutes, "uses" [remark: i.e. using other actions], and secrets on individual steps within a composite action right now.
(Note: we do support these attributes being set in workflows for a step that uses a composite run steps action)
Source: https://github.com/actions/runner/issues/646
I think using the composite action pattern, you can achieve what you want.
You need to define the steps which you think will be reused in other places, and make it parameterized, by providing inputs. In my opinion, it's more powerful than how templates work in gitlab or in other similar platforms.
This way, you are defining a function, which can take inputs, and get stuff done for you, based on those inputs.
Also, even though the docs suggest that, you should create your leaf action as a separate public repo, and use it in your base action- it's not necessary, you can simply have a structure like below(taken the example from one of our live workflow), and use those leaf actions in your workflow-
.github
- actions
- deploy-to-k8s
- action.yaml
- publish-image
- action.yaml
- workflows
- deploy-from-pr.yaml <-- this will make use of all the actions defined
Here's how the deploy-from-pr.yaml workflow looks like-
name: deploy-from-pr
on:
pull_request:
branches:
- master
env:
REGISTRY: ghcr.io
IMAGE_NAME: ${{ github.repository }}
jobs:
deploy-from-pr:
name: Deploy from PR to Development
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- name: Set version
id: release
run: echo ::set-output name=version::$(git describe --always)
# custom action to build and push image
- name: Build & publish image
uses: ./.github/actions/publish-image # see how it's referred from same repo directly
with:
registry: ${{ env.REGISTRY }}
registry_username: ${{ github.REGISTRY_USERNAME }}
registry_password: ${{ secrets.REGISTRY_PASSWORD }}
image_name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
tag: ${{ steps.release.outputs.version }}
# custom action to deploy into kubernetes
- name: Deploy to kubernetes
uses: ./.github/actions/deploy-to-k8s # see how it's referred from same repo directly
with:
digitalocean_token: ${{ secrets.DIGITALOCEAN_TOKEN }}
cluster_name: ${{ secrets.CLUSTER_NAME }}
overlay_path: .k8s/overlays/dev
image_name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
tag: ${{ steps.release.outputs.version }}
Github Gist
You can check the deploy-to-k8s/action.yaml, to see how it's written.
No, it is not. I asked the exact same question in the GitHub Forum:
Is it possible to create / publish Actions without Docker or JS by having the code in the Workflow Syntax / YML?
As mentioned in the document: Currently, types of actions only lists
Docker container and JavaScript, so there is no such feature to
achieve your requirement.
Source: https://github.community/t/how-to-create-ready-to-use-action-without-docker-js/124889/2
This would have eased creating templates for users as system administrator.
You can also use reusable workflows.
Related
I'm trying to get this github action to work but once committed it gives me this error:
Invalid workflow file: .github/workflows/main.yml#L1
No steps defined in steps and no workflow called in uses for the following jobs: build
Anyone have any idea what this might depend on?
Below is the code I used:
name: Deploy to Cloud Foundry
on:
push:
branches:
- master
jobs:
build:
runs-on: ubuntu-18.04
# Build your app here
deploy:
runs-on: ubuntu-18.04
needs: build
steps:
- uses: citizen-of-planet-earth/cf-cli-action#master
with:
cf_api: https://api.my-cloud-foundry.com
cf_username: ${{ secrets.CF_USER }}
cf_password: ${{ secrets.CF_PASSWORD }}
cf_org: AwesomeApp
cf_space: Development
command: push -f manifest-dev.yml
Thanks in advance to everyone
Following the Workflow Syntax for Github Actions, you'll identify that some fields are mandatory.
At the workflow level, you need to have at least a trigger (configure with the on field) and a list of jobs specified.
Then, in that list of jobs, you have to specify at least one job, where each of those jobs needs at least the runner and the steps (or the uses for reusable workflow) field configured.
Example of the minimum configurations you would use for a job:
on: push
jobs:
job1:
runs-on: ubuntu-latest
steps:
- name: Print a greeting
run: echo 'Hello World'
job2: # reusable workflow scenario
uses: owner/repo/.github/workflows/reusable-workflow.yml#main
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:
I have a GitHub Actions workflow implemented on the main branch of my repository which creates a new release of my package in GitHub. Then I have another workflow implemented which should be triggered on the creation of a release. This trigger, however, is not working.
Please note that GitHub abandoned their own actions/create-release#v1 project and advises to use the softprops release action.
My workflow template is as follows:
name: Main release
on:
push:
branches:
- main
jobs:
release:
name: 'Release main'
runs-on: ubuntu-latest
steps:
- name: 'Checkout source code'
uses: 'actions/checkout#v2'
with:
ref: ${{ github.ref }
- name: Release
uses: softprops/action-gh-release#v1
with:
draft: false
body_path: CHANGELOG.md
name: ${{ steps.version.outputs.version }}
tag_name: ${{ github.ref }}
token: ${{ github.token }}
My on:release:created trigger workflow is as follows:
name: Act on release created
on:
release:
types: [created]
jobs:
build:
name: Build
environment: dev_environment
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- name: Set env
run: echo "RELEASE_VERSION=${GITHUB_REF#refs/*/}" >> $GITHUB_ENV
- name: Test
run: |
echo $RELEASE_VERSION
echo ${{ env.RELEASE_VERSION }}
The release and tags are correctly added in GitHub, so everything looks to work fine except that the workflow that should be triggered on the release is not executed.
How do I solve this?
The GitHub Actions documentation on performing tasks in a workflow states the following:
When you use the repository's GITHUB_TOKEN to perform tasks on behalf of the GitHub Actions app, events triggered by the GITHUB_TOKEN will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs.
This means that you will have to create a personal access token and add this token to you repository secrets.
To generate a new personal access token go to your personal developer settings and generate a new token. Then go to your repository settings and add a new secret containing the personal access token, name it i.e. PAT.
In your release workflow template, replace:
token: ${{ github.token }}
With:
token: ${{ secrets.PAT }}
Now the on release created event the workflow will be triggered!
Note: This approach seems is a bit hacky, but is currently the only known workaround for this issue and can be considered a major design flaw of workflow integrations.
As an addendum to the answer given above, I found the workflow_run event trigger to work well for this use case:
on:
workflow_run:
workflows: ["Main release"]
types: [completed]
You can add conditions for various release tags and all if required apart from this.
I want to use Github actions to transfer files to a remote server via SFTP (only option for this server) when I push up to Github.
I am using this Action https://github.com/marketplace/actions/ftp-deploy
I have created a file in my repo in .github/workflows/main.yml and I have added:
on: push
name: Publish Website
jobs:
FTP-Deploy-Action:
name: FTP-Deploy-Action
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2.1.0
with:
fetch-depth: 2
- name: FTP-Deploy-Action
uses: SamKirkland/FTP-Deploy-Action#3.1.1
with:
ftp-server: ${{ secrets.FTP_SERVER }}
ftp-username: ${{ secrets.FTP_USERNAME }}
ftp-password: ${{ secrets.FTP_PASSWORD }}
I have created a Secret for this repo which contains the following:
FTP_SERVER: sftp.server.com, FTP_USERNAME: user, FTP_PASSWORD: password
I can see the action running in Github but it errors out on the FTP-Deploy-Action task.
##[error]Input required and not supplied: ftp-server
This is in secrets and does work with Filezilla.
Would anyone know if I've set this up wrongly?
I was able to get it working on my own repo. I think the issue may be possibly on how your secrets were setup. That error usually shows when required parameters of a github action were not provided so curious if the keys are different or whether they were saved as empty. I would delete FTP_SERVER secret and create it again to be sure.
Workflow Success Run
Workflow Code
- name: FTP-Deploy-Action
uses: SamKirkland/FTP-Deploy-Action#3.1.1
with:
ftp-server: ${{ secrets.FTP_SERVER }}
ftp-username: ${{ secrets.FTP_USERNAME }}
ftp-password: ${{ secrets.FTP_PASSWORD }}
local-dir: toupload
UPDATE: Added example per comment left below,
Example secret creation for reference. Basically create a secret per entry rather than comma separated grouped secret
Source: https://docs.github.com/en/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets
I have a workflow with an action that creates a version number when building an artefact. This version number is written to file.
How can I give that as an input to another action?
I.e: How can I use this version number as part of a commit message in another action?
Per the fabulous answer here, there's actually an inline way to accomplish this. Not intuitive at all, except that the ::set-output... syntax matches the same expected output format for GitHub Actions.
The below step loads the VERSION file into ${{ steps.getversion.outputs.version }}:
- name: Read VERSION file
id: getversion
run: echo "::set-output name=version::$(cat VERSION)"
I had the same use case as OP, so I'm pasting below my entire code, which does three things:
Pull first three-parts of the 4-part version string from the file VERSION.
Get a sequential build number using the einaregilsson/build-number#v2 action.
Concatenate these two into an always-unique 4-part version string that becomes a new GitHub release.
name: Auto-Tag Release
on:
push:
branches:
- master
jobs:
release_new_tag:
runs-on: ubuntu-latest
steps:
- name: "Checkout source code"
uses: "actions/checkout#v1"
- name: Generate build number
id: buildnumber
uses: einaregilsson/build-number#v2
with:
token: ${{secrets.github_token}}
- name: Read VERSION file
id: getversion
run: echo "::set-output name=version::$(cat VERSION)"
- uses: "marvinpinto/action-automatic-releases#latest"
with:
repo_token: "${{ secrets.GITHUB_TOKEN }}"
automatic_release_tag: v${{ steps.getversion.outputs.version }}.${{ steps.buildnumber.outputs.build_number }}
prerelease: false
Fully automated release management! :-)
Note: The branch filter at top ensures that we only run this on commits to master.
It is possible to use the filesystem to communicate between actions. But if you have input on 3rd party actions, you need to give this from the outputs of another action
Ie. you need to read this file in your action and present it as output in your action.yml. Then you can use this output as input to another action in your workflow.yaml
The accepted answer is outdated as per this blog post from GitHub.
It is still possible to do this as one step from your workflow though:
- name: Read VERSION file
id: getversion
run: echo "version=$(cat VERSION)" >> $GITHUB_OUTPUT
This will set an output named version which you can access just as before using ${{ steps.getversion.outputs.version }}:
- uses: "marvinpinto/action-automatic-releases#latest"
with:
repo_token: "${{ secrets.GITHUB_TOKEN }}"
automatic_release_tag: v${{ steps.getversion.outputs.version }}.${{ steps.buildnumber.outputs.build_number }}
prerelease: false