59e9fae189
The first implementation of the trigger-release would not push a tag,
meaning that the Release workflow was not getting triggered. While we
could have changed the Release workflow to react on "Trigger Release"
workflow runs, the inter-dependency felt awkward and brittle:
diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
index b711c5cf..843fdb70 100644
--- a/.github/workflows/release.yml
+++ b/.github/workflows/release.yml
@@ -7,10 +7,16 @@ on:
push:
tags:
- v*
+ workflow_run:
+ workflows:
+ - "Trigger Release"
+ types:
+ - completed
jobs:
goreleaser:
runs-on: ubuntu-latest
+ if: ${{ github.event.workflow_run.conclusion == 'success' }}
defaults:
run:
shell: bash
Instead of doing the above, introducing duplication between "Trigger
Release" and "Release" seemed simpler from a cognitive perspective. Now,
releases are produced via the Release workflow when tags are pushed, and
also when releases are triggered via "Trigger Release", now renamed to
"Auto Release".
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
Dagger
Dagger is a portable devkit for CICD.
Using Dagger, software teams can develop powerful CICD pipelines with minimal effort, then run them anywhere. Benefits include:
- Unify dev and CI environments. Write your pipeline once, Dagger will run it the same everywhere.
- Reduce CI lock-in. No more re-writing everything from scratch every 6 months.
How does it work?
- Automate actions with your favorite programming language. No proprietary SDK: just regular shell, Go, Javascript, Python...
- Reuse actions from a large and growing catalog.
- Tie it all together in CUE - a revolutionary declarative language invented at Google. No more YAML hell!
- Test and debug instantly on your local machine. No more waiting 10min to catch a typo.
- Run your pipelines on any Docker-compatible runtime, for maximum portability. This means most modern CI runners can run Dagger out of the box.