I have a simple nuget pipeline using github actions workflow where i want to create a new release of a nuget package when i push a release/vx.x.x branch.I have setup gitversion with the following configuration:
next-version: 6.0
mode: ContinuousDeployment
tag-prefix: '[vV]'
increment: Inherit
branches:
master:
regex: master$
increment: Patch
main:
regex: main$
increment: Patch
release:
regex: r(elease$|(eleases)?[-/])
mode: ContinuousDelivery
increment: Minor
is-release-branch: true
This works well to create a pre release when i merge a pr to main, but to get a release to be created as a new version i have to tag the version number and make it an official release in github.
Is there a way to do this automatically?
Related
This question already has an answer here:
GitHub Actions auto-approve not working on pull request created by GitHub Actions bot
(1 answer)
Closed 7 months ago.
I implemented a workflow that runs once a week and updates all the project dependencies and opens a PR with its changes using the workflow token.
name: Automatic dependency update
"on":
workflow_dispatch: null
schedule:
- cron: 0 0 * * 1
jobs:
update:
name: Update to latest versions
runs-on:
- self-hosted
- default-runner
steps:
- name: Checkout Project
uses: actions/checkout#v2
- name: Install Java
uses: actions/setup-java#v2
- name: Update Versions
run: |
./gradlew useLatestVersions --info
- name: Commit and open PR
uses: peter-evans/create-pull-request#v3
with:
commit-message: Update to latest versions
committer: Update Bot <workflow#xxx.com>
branch: auto-dependency-update
base: dev
delete-branch: true
title: Automatic dependency update
draft: false
team-reviewers: XX/teamname
body: Automated gradle dependency updates
The issue is, that for this PR the normal workflows (that are mandatory for the PR merge are not triggered.
name: Build pipeline
"on":
workflow_dispatch: null
pull_request:
branches:
- dev
push:
branches:
- '!master'
- '**'
defaults:
run:
shell: bash
jobs:
build:
name: Compile
runs-on:
- self-hosted
- default-runner
steps:
- name: Checkout code
uses: actions/checkout#v2
- uses: actions/setup-java#v2
- name: Compile code
run: |
./gradlew classes testClasses --info
# ...
When I manually push something to that branch, the workflows are triggered. Though when I add the following step to the version update workflow, then the workflows aren't triggered either.
So what can I do? I dont want to trigger the workflows explicityl (e.g. using benc-uk/workflow-dispatch#v1) to keep the update mechanism as generic as possible.
According to the official documentation
When you use the repository's GITHUB_TOKEN to perform tasks, 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.
For more information, see "Authenticating with the GITHUB_TOKEN."
The action you're using to open the PR also states in the Inputs section that you can change the GITHUB_TOKEN scope as well, or use a PAT:
GITHUB_TOKEN (permissions contents: write and pull-requests: write) or a repo scoped Personal Access Token (PAT).
Solution
Therefore, you just need to add a token input to the peter-evans/create-pull-request action using a secret allowing you to trigger a workflow from another workflow.
I have private repo A (which is a library) and that repo has releases. Now I have repo B which has a dependency on the artifacts of A. The dependency (i.e. which version) is stored in a json file in B. What I'm looking for is a way to download the artifacts of release X from repo A in an action/workflow in repo B.
I have seen a lengthy bash script which make this possible, but I'm wondering if there are off the shelf actions around.
If you are using a Linux runner, you can use the Fetch Github Release Asset action.
uses: dsaltares/fetch-gh-release-asset#master
with:
repo: "user/repo"
version: "tags/v1"
file: "filename.ext"
target: "targetFolder/targetFileName.ext"
token: ${{ secrets.PAT_TO_ACCESS_PRIVATE_REPO }}
Inputs
token
Required The GitHub token. Typically this will be ${{ secrets.GITHUB_TOKEN }}
file
Required The name of the file to be downloaded.
repo
The org/repo containing the release. Defaults to the current repo.
version
The release version to fetch from in the form tags/<tag_name> or <release_id>. Defaults to latest.
target
Target file path. Only supports paths to subdirectories of the GitHub Actions workspace directory
Can I trigger a new workflow from another workflow?
I'm trying to run a workflow after the first workflow has pushed a new release and it seems to ignore it.
Found the answer here:
An action in a workflow run can't trigger a new workflow run. For example, if an action 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.
EDIT:
The quote above might be confusing. When I add a Personal Access Token (PAT) to the checkout action with repo permissions granted (and not repository's GITHUB_TOKEN), the following commands DO trigger other workflows:
- name: Checkout Repo
uses: actions/checkout#v2
with:
token: ${{ secrets.PAT_TOKEN }}
(In my case, running semnatic-release after this checkout, which creates a new release with a new tag - did trigger another workflow that runs only if a tag was created)
As described here, you can trigger another workflow using the workflow_run event.
For example we could think of two workflow definitions like this (the only prerequisite is, that both reside in the same repository - but I'am sure, there's also an event for other repos as well):
release.yml
name: CI release
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- name: Release artifact
run: ...
do-something-different.yml
name: Do anything after the release of the first workflow
on:
workflow_run:
workflows: ["CI release"]
types:
- completed
jobs:
notify:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- name: Do something
run: ...
A crucial point here is that the name: CI release definition of the first yaml file must exactly match the workflow_run: workflows: ["CI release"] definition in the second yaml file. Another point is that this approach needs to be done on the default branch (which is mostly main or master) as the docs state:
Note: This event will only trigger a workflow run if the workflow file
is on the default branch.
If you don't want to use a general Personal Access Token (which has access to all of your repos), you can generate a dedicated SSH keypair for this purpose and add it to the repository as a Deploy Key. This is done as follows:
Generate an SSH keypair:
ssh-keygen -N "" -f deploy_key -C "github-actions"
Add the private key (generated file deploy_key) as an encryped secret, e.g. COMMIT_KEY to the GitHub project.
Add the public key (generated file deploy_key.pub) as a deploy key with write access to the GitHub project. Tick the Allow write access checkbox.
When checking out the source code in your workflow, add the SSH key:
- name: Checkout
uses: actions/checkout#v3
with:
ssh-key: "${{secrets.COMMIT_KEY}}"
Subsequent push actions in the same workflow will then trigger any configured GitHub workflow as if they were pushed manually.
Is it possible to reference another GitHub Action from my action.yml file?
Note, I'm talking about an action here, not a workflow. I know this can be done with workflows, but can actions reference other actions?
The answer seems to be: You can (now, Aug. 2021)
GitHub Actions: Reduce duplication with action composition
Previously, actions written in YAML could only use scripts.
Now, they can also reference other actions.
This makes it easy to reduce duplication in your workflows.
For example, the following action uses 3 actions to setup buildx, log in to Docker, and publish an image.
By combining these into a single action it provides a larger unit of reuse that you can put into the job of any workflow.
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
Developers can then reference this action in all of their repositories as a single action:
on: [push]
jobs:
publish:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- uses: my-org/publish-docker#v1
with:
registry_username: ${{secrets.REGISTRY_USERNAME}}
registry_password: ${{secrets.REGISTRY_PASSWORD}}
Learn more about action composition.
So, as described in "runs for composite actions":
runs.steps[*].uses
[Optional] Selects an action to run as part of a step in your job.
An action is a reusable unit of code.
You can use an action defined in the same repository as the workflow, a public repository, or in a published Docker container image.
We strongly recommend that you include the version of the action you are using by specifying a Git ref, SHA, or Docker tag number.
If you don't specify a version, it could break your workflows or cause unexpected behavior when the action owner publishes an update.
runs:
using: "composite"
steps:
# Reference a specific commit
- uses: actions/checkout#a81bbbf8298c0fa03ea29cdc473d45769f953675
# Reference the major version of a release
- uses: actions/checkout#v2
# Reference a specific version
- uses: actions/checkout#v2.2.0
# Reference a branch
- uses: actions/checkout#main
# References a subdirectory in a public GitHub repository at a specific branch, ref, or SHA
- uses: actions/aws/ec2#main
# References a local action
- uses: ./.github/actions/my-action
# References a docker public registry action
- uses: docker://gcr.io/cloud-builders/gradle
# Reference a docker image published on docker hub
- uses: docker://alpine:3.8
The answer seems to be: You can't.
However, I ended up internally downloading the different actions from NPM, and then re-using them within my own action.
Probably not a good idea in general, but this particular action I am making is designed to run on my own projects without requiring too much configuration, so that makes it more okay.
If both actions are nodejs actions you are serving over GitHub and you don't mind them reading the one set of input, this works pretty well:
npm install --save MyGitHubOrg/MyRepo#master
git add -f node_modules/ package.json package-lock.json
async function run() {
try {
require('my-action');
} catch (err) {
core.setFailed(`Failed to run habitat-action: ${err.message}`);
return;
}
// ...
}
GitHub actions allow the use of branch and tag filters, but they don't seem to work together.
For example, this workflow runs on pushes to master or pushes with a tag.
name: npm Publish
on:
push:
branches:
- master
tags:
- v*
I want to setup a publishing workflow that runs on tagged pushes to master, not just one or the other. How can this be done?
One solution is to use on: release instead of on: push. This will trigger the workflow to execute when a release is published via the GitHub UI. When you publish a release on GitHub it tags the master branch with the version of the release that you specify. Each execution of the workflow is therefore guaranteed to be a tagged commit on the master branch.
name: npm Publish
on: release