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>
This commit is contained in:
Gerhard Lazu 2022-01-10 12:30:00 +00:00
parent 180beee9c7
commit fcdda0b072
No known key found for this signature in database
GPG Key ID: A28DE70C9444D7A6
2 changed files with 71 additions and 0 deletions

View File

@ -1,8 +1,13 @@
name: Release name: Release
# Only a single job with this concurrency can run at any given time
concurrency: release
on: on:
push: push:
tags: tags:
- v* - v*
jobs: jobs:
goreleaser: goreleaser:
runs-on: ubuntu-latest runs-on: ubuntu-latest

66
.github/workflows/trigger-release.yml vendored Normal file
View File

@ -0,0 +1,66 @@
name: "Trigger Release"
# 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:
workflow_dispatch:
inputs:
tag:
description: 'Custom tag (default bumps last tag) DO NOT prefix with v'
required: false
jobs:
bump_version-tag-push:
name: "Bump version, tag & push"
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 & push"
allowed-conclusions: success
- name: "Tag so that a new release is triggered"
id: tag_version
# https://github.com/mathieudutour/github-tag-action
uses: mathieudutour/github-tag-action@v6.0
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
fetch_all_tags: true
custom_tag: "${{ github.event.inputs.tag }}"
# This is OK for now, but let's revisit this around February 2022
release_branches: "there_are_only_prereleases_for_now"
# When we start auto-bumping patches/minors, consider removing pre-releases
pre_release_branches: "main"
append_to_pre_release_tag: "alpha"
# Set to true when you are testing / experimenting
dry_run: false
# This may be of interest when we need more control over the version bumps
# https://github.com/craig-day/compute-tag