This repository has been archived on 2024-04-08. You can view files and clone it, but cannot push or open issues or pull requests.
dagger/.github/workflows/auto-release.yml

94 lines
3.5 KiB
YAML
Raw Normal View History

name: "Auto Release"
Add GitHub Workflow that triggers a release at a regular time in the week While talking with @aluzzardi, we thought that regular auto-releases which happen with no intervention on our part would be a good idea. The last Dagger release (0.1.0-alpha.31) was over 1 month ago, and there are Europa-related changes which we want to make available in the Dagger GitHub Action. We should never have more than 1 week of unreleased changes. While more often is better, and we may need to tweak this later, this is a decent starting point: release every Tuesday, 5pm UTC & 9am SFO. We had to adjust the starting point slightly so that we do not start at the top of the hour when there is high load on GitHub Actions (see the inline comments for more details) The workflow can also be triggered manually, and a custom tag can be provided optionally. If no tag is provided, the last one will be incremented as expected, e.g. v0.1.0-alpha.31 -> v0.1.0-alpha.32. Before you get too carried away with custom tags, let's talk about the unexpected side-effects which are not worth covering in this commit message ("people over processes"). There is also a concurrency setting which will not prevent multiple releases to be triggered, but at least these jobs will not run in parallel. I looked into cancelling the current workflow if another one of the same type is running, but I couldn't get it to work properly within my 30 mins time-box so I stopped. There is a lot to talk about our releases AFTER this gets merged, so let's defer those conversations until we are happy with the first step which I think is in the right direction. Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
2022-01-10 13:30:00 +01:00
# Only a single job with this concurrency can run at any given time
concurrency: release
on:
# This runs on a schedule by default:
schedule:
# https://crontab.guru/#6_17_*_*_2
# Every Tuesday at 5:06pm UTC & 9:06am US West Coast.
# GitHub Actions defaults to UTC:
- cron: '6 17 * * 2'
# There is high load on GitHub Actions at the top of the hour:
#
# Note: The schedule event can be delayed during periods of high loads of
# GitHub Actions workflow runs. High load times include the start of every
# hour. To decrease the chance of delay, schedule your workflow to run at a
# different time of the hour.
#
# So we run these at a special time, 9:06. Ask @gerhard about it.
# And it also supports manual triggering:
# https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_dispatchinputs
Add GitHub Workflow that triggers a release at a regular time in the week While talking with @aluzzardi, we thought that regular auto-releases which happen with no intervention on our part would be a good idea. The last Dagger release (0.1.0-alpha.31) was over 1 month ago, and there are Europa-related changes which we want to make available in the Dagger GitHub Action. We should never have more than 1 week of unreleased changes. While more often is better, and we may need to tweak this later, this is a decent starting point: release every Tuesday, 5pm UTC & 9am SFO. We had to adjust the starting point slightly so that we do not start at the top of the hour when there is high load on GitHub Actions (see the inline comments for more details) The workflow can also be triggered manually, and a custom tag can be provided optionally. If no tag is provided, the last one will be incremented as expected, e.g. v0.1.0-alpha.31 -> v0.1.0-alpha.32. Before you get too carried away with custom tags, let's talk about the unexpected side-effects which are not worth covering in this commit message ("people over processes"). There is also a concurrency setting which will not prevent multiple releases to be triggered, but at least these jobs will not run in parallel. I looked into cancelling the current workflow if another one of the same type is running, but I couldn't get it to work properly within my 30 mins time-box so I stopped. There is a lot to talk about our releases AFTER this gets merged, so let's defer those conversations until we are happy with the first step which I think is in the right direction. Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
2022-01-10 13:30:00 +01:00
workflow_dispatch:
inputs:
release_type:
description: 'major|minor|patch|release|prerel'
default: 'prerel alpha..'
required: true
release_version:
description: 'Optional release version, e.g. 0.2.0'
Add GitHub Workflow that triggers a release at a regular time in the week While talking with @aluzzardi, we thought that regular auto-releases which happen with no intervention on our part would be a good idea. The last Dagger release (0.1.0-alpha.31) was over 1 month ago, and there are Europa-related changes which we want to make available in the Dagger GitHub Action. We should never have more than 1 week of unreleased changes. While more often is better, and we may need to tweak this later, this is a decent starting point: release every Tuesday, 5pm UTC & 9am SFO. We had to adjust the starting point slightly so that we do not start at the top of the hour when there is high load on GitHub Actions (see the inline comments for more details) The workflow can also be triggered manually, and a custom tag can be provided optionally. If no tag is provided, the last one will be incremented as expected, e.g. v0.1.0-alpha.31 -> v0.1.0-alpha.32. Before you get too carried away with custom tags, let's talk about the unexpected side-effects which are not worth covering in this commit message ("people over processes"). There is also a concurrency setting which will not prevent multiple releases to be triggered, but at least these jobs will not run in parallel. I looked into cancelling the current workflow if another one of the same type is running, but I couldn't get it to work properly within my 30 mins time-box so I stopped. There is a lot to talk about our releases AFTER this gets merged, so let's defer those conversations until we are happy with the first step which I think is in the right direction. Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
2022-01-10 13:30:00 +01:00
required: false
jobs:
bump_version-tag-release:
# ⚠️ If this changes, remember to update the running-workflow-name property
name: "Bump version, tag & release"
Add GitHub Workflow that triggers a release at a regular time in the week While talking with @aluzzardi, we thought that regular auto-releases which happen with no intervention on our part would be a good idea. The last Dagger release (0.1.0-alpha.31) was over 1 month ago, and there are Europa-related changes which we want to make available in the Dagger GitHub Action. We should never have more than 1 week of unreleased changes. While more often is better, and we may need to tweak this later, this is a decent starting point: release every Tuesday, 5pm UTC & 9am SFO. We had to adjust the starting point slightly so that we do not start at the top of the hour when there is high load on GitHub Actions (see the inline comments for more details) The workflow can also be triggered manually, and a custom tag can be provided optionally. If no tag is provided, the last one will be incremented as expected, e.g. v0.1.0-alpha.31 -> v0.1.0-alpha.32. Before you get too carried away with custom tags, let's talk about the unexpected side-effects which are not worth covering in this commit message ("people over processes"). There is also a concurrency setting which will not prevent multiple releases to be triggered, but at least these jobs will not run in parallel. I looked into cancelling the current workflow if another one of the same type is running, but I couldn't get it to work properly within my 30 mins time-box so I stopped. There is a lot to talk about our releases AFTER this gets merged, so let's defer those conversations until we are happy with the first step which I think is in the right direction. Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
2022-01-10 13:30:00 +01:00
runs-on: ubuntu-latest
steps:
- name: "Check out"
uses: actions/checkout@v2
with:
fetch-depth: 0
- name: "Ensure that all other checks have succeeded"
# https://github.com/lewagon/wait-on-check-action
uses: lewagon/wait-on-check-action@v1.0.0
with:
ref: ${{ github.ref }}
repo-token: ${{ secrets.GITHUB_TOKEN }}
wait-interval: 10 # polls the GitHub API every 10 every seconds
running-workflow-name: "Bump version, tag & release"
Add GitHub Workflow that triggers a release at a regular time in the week While talking with @aluzzardi, we thought that regular auto-releases which happen with no intervention on our part would be a good idea. The last Dagger release (0.1.0-alpha.31) was over 1 month ago, and there are Europa-related changes which we want to make available in the Dagger GitHub Action. We should never have more than 1 week of unreleased changes. While more often is better, and we may need to tweak this later, this is a decent starting point: release every Tuesday, 5pm UTC & 9am SFO. We had to adjust the starting point slightly so that we do not start at the top of the hour when there is high load on GitHub Actions (see the inline comments for more details) The workflow can also be triggered manually, and a custom tag can be provided optionally. If no tag is provided, the last one will be incremented as expected, e.g. v0.1.0-alpha.31 -> v0.1.0-alpha.32. Before you get too carried away with custom tags, let's talk about the unexpected side-effects which are not worth covering in this commit message ("people over processes"). There is also a concurrency setting which will not prevent multiple releases to be triggered, but at least these jobs will not run in parallel. I looked into cancelling the current workflow if another one of the same type is running, but I couldn't get it to work properly within my 30 mins time-box so I stopped. There is a lot to talk about our releases AFTER this gets merged, so let's defer those conversations until we are happy with the first step which I think is in the right direction. Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
2022-01-10 13:30:00 +01:00
allowed-conclusions: success
- name: "Create next release tag"
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
if [[ -n "${{ github.event.inputs.release_version }}" ]]
then
next_release_version="v${{ github.event.inputs.release_version }}"
else
previous_release_version="$(gh api /repos/:owner/:repo/releases --jq '.[0].tag_name')"
echo "PREVIOUS RELEASE VERSION: $previous_release_version"
# Rather than installing it on every run, we commit it locally so that we have everything we need locally
# wget https://raw.githubusercontent.com/fsaintjacques/semver-tool/3.3.0/src/semver
# https://github.com/fsaintjacques/semver-tool
next_release_version="v$(./semver bump ${{ github.event.inputs.release_type }} $previous_release_version)"
fi
echo "NEXT RELEASE VERSION: $next_release_version"
gh api -X POST /repos/:owner/:repo/git/refs \
--field ref="refs/tags/$next_release_version" \
--field sha="$GITHUB_SHA"
- name: "Fetch new tag"
uses: actions/checkout@v2
Add GitHub Workflow that triggers a release at a regular time in the week While talking with @aluzzardi, we thought that regular auto-releases which happen with no intervention on our part would be a good idea. The last Dagger release (0.1.0-alpha.31) was over 1 month ago, and there are Europa-related changes which we want to make available in the Dagger GitHub Action. We should never have more than 1 week of unreleased changes. While more often is better, and we may need to tweak this later, this is a decent starting point: release every Tuesday, 5pm UTC & 9am SFO. We had to adjust the starting point slightly so that we do not start at the top of the hour when there is high load on GitHub Actions (see the inline comments for more details) The workflow can also be triggered manually, and a custom tag can be provided optionally. If no tag is provided, the last one will be incremented as expected, e.g. v0.1.0-alpha.31 -> v0.1.0-alpha.32. Before you get too carried away with custom tags, let's talk about the unexpected side-effects which are not worth covering in this commit message ("people over processes"). There is also a concurrency setting which will not prevent multiple releases to be triggered, but at least these jobs will not run in parallel. I looked into cancelling the current workflow if another one of the same type is running, but I couldn't get it to work properly within my 30 mins time-box so I stopped. There is a lot to talk about our releases AFTER this gets merged, so let's defer those conversations until we are happy with the first step which I think is in the right direction. Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
2022-01-10 13:30:00 +01:00
with:
fetch-depth: 0
Add GitHub Workflow that triggers a release at a regular time in the week While talking with @aluzzardi, we thought that regular auto-releases which happen with no intervention on our part would be a good idea. The last Dagger release (0.1.0-alpha.31) was over 1 month ago, and there are Europa-related changes which we want to make available in the Dagger GitHub Action. We should never have more than 1 week of unreleased changes. While more often is better, and we may need to tweak this later, this is a decent starting point: release every Tuesday, 5pm UTC & 9am SFO. We had to adjust the starting point slightly so that we do not start at the top of the hour when there is high load on GitHub Actions (see the inline comments for more details) The workflow can also be triggered manually, and a custom tag can be provided optionally. If no tag is provided, the last one will be incremented as expected, e.g. v0.1.0-alpha.31 -> v0.1.0-alpha.32. Before you get too carried away with custom tags, let's talk about the unexpected side-effects which are not worth covering in this commit message ("people over processes"). There is also a concurrency setting which will not prevent multiple releases to be triggered, but at least these jobs will not run in parallel. I looked into cancelling the current workflow if another one of the same type is running, but I couldn't get it to work properly within my 30 mins time-box so I stopped. There is a lot to talk about our releases AFTER this gets merged, so let's defer those conversations until we are happy with the first step which I think is in the right direction. Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
2022-01-10 13:30:00 +01:00
- name: "Install Go"
uses: actions/setup-go@v2
with:
go-version: 1.16
- name: "Release"
uses: goreleaser/goreleaser-action@v2
with:
args: release --rm-dist --debug
env:
GITHUB_TOKEN: ${{ secrets.DAGGERCI_TOKEN }}
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
AWS_REGION: us-east-1