GitHub Actions on release created workflow trigger not working - github

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.

Related

What permissions are needed for Github Actions to create a tag and release for a Protected Tag?

I was reading about protected tags and how they can be created
on Github through the Settings tab of a particular repository.
I have a github actions workflow which:
Creates a new release
Since it creates a new release, it also creates a new tag
Uploads files and data to the release
Here is an example of my workflow, which has only some of the key parts.
name: myExample
on:
push:
branches: [ master ]
permissions:
contents: write
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v3
- name: Set up Python 3.8.3
uses: actions/setup-python#v3
with:
python-version: "3.8.3"
... Some Steps ...
- name: Create Release
id: create_release
uses: actions/create-release#v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
tag_name: ${{env.VERSION}}
release_name: ${{env.RELEASE_STRING}}
draft: false
prerelease: false
- name: Upload Release Asset 1
id: upload-release-asset-1
uses: actions/upload-release-asset#v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
upload_url: ${{ steps.create_release.outputs.upload_url }}
asset_path: ./test.zip
asset_name: test.zip
asset_content_type: application/zip
... Some Steps ...
I imagine I need to primarily focus on the section:
permissions:
contents: write
What do I need to change so that this workflow can write protected tags and generally can work with protected tags?
Currently, my rule for protected tags is:
*
According to this article, it says "GitHub Apps require the Repository administration: write permission to modify a protected tag."
I looked at Github Actions permissions in this article, but I don't see those permissions.
I now thought I need to create a Personal Access Token and use it according to this article and this article. When creating a PAT, I didn't immediately see exactly what was described above with Repository administration: write. Perhaps if I'm an admin or maintainer of the repo, then if I create a PAT with full repo permissions then that would do it, since the token is associated with me who is admin and therefore, I can create a release on the protected branch as an admin. I haven't tested this yet, it is just a theory after searching around.
You can set the permissions at a job level so rather than grant the whole action, you set write and can limit to the job:
version:
permissions: write-all
name: versioning
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v3.3.0
with:
fetch-depth: '0'
- name: Bump version and push tag
uses: anothrNick/github-tag-action#1.61.0
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
DEFAULT_BUMP: patch
WITH_V: "true"
needs: [terraform, security]
You can create a Personal Access Token of your account or one of a technical user and use this token while checking out the repo:
- name: Checkout
uses: actions/checkout#v3
with:
token: ${{ secrets.PAT }}
The used account need to admin of the repo, then you will be able to update the protected tag whithin github action

Automating a PR merge followed by opening a new PR

I have a branch called stage and currently have a workflow that runs when a PR is labeled (to merge into the stage branch), and I'm currently trying to create a workflow that happens if the branch is successfully automerge.
For example -- here's a working example of the workflow to the stage branch:
name: PR opened to stage
on:
pull_request:
types: [labeled]
branches: [ stage ]
jobs:
audit-checks:
runs-on: self-hosted
steps:
- uses: actions/checkout#v2
if: contains(github.event.pull_request.labels.*.name, 'ready')
- name: Enable Auto Merge
uses: peter-evans/enable-pull-request-automerge#v1
if: contains(github.event.pull_request.labels.*.name, 'ready')
with:
token: ${{ secrets.GITHUB_TOKEN }}
pull-request-number: ${{ github.event.pull_request.number }}
merge-method: merge
And here's another workflow that, when a PR to stage is closed, is supposed to run. I have a step as well that checks to see if the label includes ready and is supposed to create another PR to another branch:
name: ready for prod test
on:
pull_request:
types: [closed]
branches: [ stage ]
jobs:
audit-checks:
runs-on: self-hosted
steps:
- uses: actions/checkout#v2
- name: automate PR creation for prod
if: |
${{ github.event.pull_request.merged }} && contains(github.event.pull_request.labels.*.name, 'ready')
uses: peter-evans/create-pull-request#v3
with:
token: ${{ secrets.GITHUB_TOKEN }}
branch: stage
base: prod
labels: ready
title: Automated PR opened
It seems that when the PR is initially opened and labeled ready, the first workflow runs just fine. However, once that workflow enables auto merge and it actually auto-merges (upon completion of the workflow), the second workflow doesn't ever get triggered.
Is it possible that the second workflow is somehow running before the first one completes and doesn't actually do anything because of it? I'm not sure it's anything in my 2nd job (at least not yet) since it hasn't even run (or run and fail).
Just found my answer here: https://docs.github.com/en/actions/security-guides/automatic-token-authentication
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. For example, if a workflow run
pushes code using the repository's GITHUB_TOKEN, a new workflow will
not run even when the repository contains a workflow configured to run
when push events occur.

Create pull request with github action

I'm trying to make it work this action, but I'm confused also whats it's missing in between, before triggering the peter-evans PR.
The scenario is pretty simple, I like on push, on any feature/* branch, to create automatically PR, but instead I'm getting weird scenario, where develop changes are applied on top of the feature/* branch. Can someone give me hints on this?
name: Pull Request Action
on:
push:
branches:
- feature/*
jobs:
create-pull-request:
runs-on: ubuntu-latest
steps:
- name: Check out repository code
uses: actions/checkout#v2
with:
fetch-depth: 0
ref: develop
- name: Create Pull Request
uses: peter-evans/create-pull-request#v3.10.0
with:
token: ${{ secrets.GITHUB_TOKEN }}
commit-message: Simple demo
title: '[Example] Simple demo'
body: >
This PR is auto-generated by
[create-pull-request](https://github.com/peter-evans/create-pull-request).
labels: feature, automated pr
branch: feature/workflow-demo
Just posting this as an alternative solution. If you don't want to use any 3rd party actions you can achieve this with actions/github-script, it will just require a bit more coding.
As this stands, the action will error if there is already an open PR for the feature branch. If this is an issue you could check of an existing PR with the github.rest.pulls.list method, filtering by both head and base so it will only return one or no PRs.
name: Pull Request Action
on:
push:
branches:
- feature/*
jobs:
create-pull-request:
runs-on: ubuntu-latest
steps:
- name: Create Pull Request
uses: actions/github-script#v6
with:
script: |
const { repo, owner } = context.repo;
const result = await github.rest.pulls.create({
title: '[Example] Simple demo',
owner,
repo,
head: '${{ github.ref_name }}',
base: 'develop',
body: [
'This PR is auto-generated by',
'[actions/github-script](https://github.com/actions/github-script).'
].join('\n')
});
github.rest.issues.addLabels({
owner,
repo,
issue_number: result.data.number,
labels: ['feature', 'automated pr']
});
I know this question is a year old now and asking about the create-pull-request action, but for those that would rather not use third-party actions, Github actions now support Github command line natively, if you use Github hosted runners. See: Using Github CLI in Workflows
This makes it super easy to create a pull request using the gh pr create command
Something like this:
steps:
- name: create pull request
run: gh pr create -B base_branch -H branch_to_merge --title 'Merge branch_to_merge into base_branch' --body 'Created by Github action'
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Reading through the readme, the action by Peter Evans doesn't fit what you're trying to achieve. But you can use repo-sync's pull-request action:
name: Pull Request Action
on:
push:
branches:
- feature/*
jobs:
create-pull-request:
runs-on: ubuntu-latest
steps:
- name: Check out repository code
uses: actions/checkout#v2
- name: pull-request
uses: repo-sync/pull-request#v2
with:
destination_branch: "develop"
github_token: ${{ secrets.GITHUB_TOKEN }}
pr_label: "feature, automated pr"
pr_title: "[Example] Simple demo"
You might need to specify the base branch there:
- name: Create Pull Request
uses: peter-evans/create-pull-request#v3.10.1
with:
token: ${{ secrets.GH_TOKEN }}
commit-message: Auto Pull Request
title: Your desired title
body: Auto-created Pull Request
branch: ${{ github.ref }} # The branch where you commit
base: develop # Don't forget to specify the right base branch here
I have this and it creates the PR when it does not exist. I remember it didn't work exactly right at the beginning until I specified myself base and branch values, which are not very clear in the docs.

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