Reusable workflow not being invoked on release action in Github - github

I hope someone can help me out with this github action issue.
I am trying to set a github action pipeline that parse the some tags and invoke another reusable workflow.
Here is what the code looks like:
name: release per tag
on:
release:
types: [ published ]
permissions:
actions: write
checks: write
contents: write
deployments: write
issues: write
packages: write
pull-requests: write
repository-projects: write
security-events: write
statuses: write
jobs:
get_project_folder:
name: "Find project folder"
runs-on: ubuntu-latest
outputs:
project_folder: ${{ steps.regex-match.outputs.name }}
steps:
- id: regex-match
uses: actions-ecosystem/action-regex-match#v2
with:
text: ${{ github.event.release.tag_name }}
regex: '.*(?=\-)'
- id: to-variable
run: echo "::set-output name=project_name::${{ steps.regex-match.outputs.match }}"
build_release_package:
name: "Invoke standard release tag yaml"
uses: ./.github/workflows/standard_release_tag.yaml
with:
project_name: ${{ needs.get_project_folder.outputs.project_folder }}
environment: Production
secrets:
INSTALL_PKG_PAT: ${{ secrets.INSTALL_PKG_PAT }}
HOST_URL: ${{ secrets.HOST_URL }}
ACCESS_TOKEN: ${{ secrets.ACCESS_TOKEN }}
ENV: prod
Somehow this pipeline is not being able to call the standard_release_tag.yaml even it exists on the repository.
Is this something happened to anyone? I googled but only saw this happen for a different trigger event and was fixed by Github team.
Thanks.

Solved by validating that the pipeline was invoking and old version of the yaml pipeline.

Related

How can I run a GitHub Actions job based on a complex condition (specific label removed)?

I have two reusable workflows to deploy and destroy GCP resources, which I call from one workflow based on different conditions.
One workflow creates infra and is triggered when the label preview is added to a PR:
on:
pull_request:
types: [opened, reopened, labeled]
jobs:
create-infrastructure:
if: ${{ contains( github.event.pull_request.labels.*.name, 'preview') }}
# Call to a reusable workflow here
The second workflow I need to trigger when the PR is closed or when a specific label is removed; I tried this:
on:
pull_request:
types: [ closed, unlabeled ]
jobs:
destroy_preview:
if: ${{ contains( github.event.pull_request.labels.*.name, 'preview') }}
uses: myrepo/.github/workflows/preview-app-destroy.yml#v0.3.6
with:
project_id: xxx
I don't know how to define unlabeled for a specific label. It would be great if someone has any idea.
The pull request webhook payload doesn't contain the removed label, as far as I can tell, but you can fetch the list of issue events (which work for pull requests, too), filter by unlabeled events, and then look at the label name of the last one.
Using the GitHub CLI in a run step, that might look something like this:
name: Preview removed workflow
on:
pull_request:
types:
- unlabeled
jobs:
destroy_preview:
runs-on: ubuntu-20.04
steps:
- name: Check if "preview" was removed
env:
GITHUB_TOKEN: ${{ github.token }}
run: |
pr=${{ github.event.number }}
label=$(gh api "repos/$GITHUB_REPOSITORY/issues/$pr/events" \
--jq 'map(select(.event == "unlabeled"))[-1].label.name')
if [[ $label == 'preview' ]]; then
echo "The 'preview' label has been removed"
fi
where you'd replace the echo with your infrastructure commands.
Now, if you want to call a reusable workflow when that specific label is removed, you have to somehow find a way to add a condition to the job where the reusable workflow is called.
One option is to make two jobs, one to check the condition and setting the result as a job output. The other job is set up as depending on the first one, and its if condition checks if the output was set to true.
This would look something like this (omitting the name and trigger, as they are identical to above):
jobs:
checklabel:
runs-on: ubuntu-20.04
outputs:
waspreview: ${{ steps.check.outputs.preview }}
steps:
- name: Check if "preview" was removed
id: check
env:
GITHUB_TOKEN: ${{ github.token }}
run: |
pr=${{ github.event.number }}
label=$(gh api "repos/$GITHUB_REPOSITORY/issues/$pr/events" \
--jq 'map(select(.event == "unlabeled"))[-1].label.name')
if [[ $label == 'preview' ]]; then
echo "::set-output name=preview::true"
fi
destroy_preview:
needs: checklabel
if: needs.checklabel.outputs.waspreview
uses: myrepo/.github/workflows/preview-app-destroy.yml#v0.3.6
with:
project_id: xxx

In a GitHub Action how to conditionalize a step based off the previous step's output?

Building a GitHub action based on the commit message I'm trying to base a step on whether the commit message contains a particular string, set it to a variable and then in the next step check with a condition.
My current implementation of my action works:
name: Smoke Test
on:
push:
branches:
- main
permissions:
contents: read
issues: write
jobs:
smoking:
runs-on: [ubuntu-latest]
steps:
- name: Run smoke tests
if: ${{ !contains(github.event.head_commit.message, 'smoke_test') }}
run: |
echo 'Smoke Test not requested'
exit 1
stuff:
needs: smoking
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- uses: JasonEtco/create-an-issue#v2
env:
GITHUB_TOKEN: ${{ secrets.TOKEN }}
with:
filename: .github/ISSUE_TEMPLATE/smoke-test.md
id: create-issue
- run: 'echo Created issue number ${{ steps.create-issue.outputs.number }}'
- run: 'echo Created ${{ steps.create-issue.outputs.url }}'
but with the implementation of:
exit 1
causes the action to indicate it error'ed out in the action panel and while that works that isn't technically accurate because I don't need it to error I just don't want the remaining steps to run.
I've tried setting a variable:
if: ${{ contains(github.event.head_commit.message, 'smoke_test') }}
with:
run-smoke-test: true
run: |
echo 'Smoke Test requested'
but it's not passing to the next step.
Research
Use environment variable in github action if
How to pass variable between two successive GitHub Actions jobs?
github-action: does the IF have an ELSE?
How to fail a job in GitHub Actions?
GitHub Actions - trigger another action after one action is completed
Without relying on another GitHub action is there a way in step smoking to set an env variable that step stuff would need to validate for before running the step?
Edit
After reading the answer and implementing job outputs I've written:
name: Smoke Test
on:
push:
branches:
- main
permissions:
contents: read
issues: write
jobs:
commitMessage:
runs-on: ubuntu-latest
outputs:
output1: ${{ steps.isSmoke.outputs.test }}
steps:
- id: isSmoke
if: ${{ contains(github.event.head_commit.message, 'smoke_test') }}
run: echo "::set-output name=test::true"
smokeTest:
runs-on: ubuntu-latest
needs: commitMessage
steps:
- uses: actions/checkout#v2
- uses: JasonEtco/create-an-issue#v2
if: steps.isSmoke.output.test == true
env:
GITHUB_TOKEN: ${{ secrets.DEV_TOKEN }}
with:
filename: .github/ISSUE_TEMPLATE/smoke-test.md
but when the commit message of smoke_test is used it bypasses create-an-issue:
and I'm basing my condition after reading "Run github actions step based on output condition" and reading:
Contexts
Expressions
Using conditions to control job execution
Can a condition come before a step and/or what is the correct way to run a step based off the previous step?
You are looking for job outputs, which allow you to send data to the following jobs.

GitHub Actions on release created workflow trigger not working

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.

Nested templates (calling a yaml file from another yaml file) in GitHub Actions

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.

How to SFTP with Github Actions?

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