- Each package can include its own bats file (e.g. `universe.dagger.io/yarn/test/yarn.bats`)
- universe.dagger.io includes a common bash helper file
- bats is installed/launched through yarn with minimal setup
- shellcheck is done across the entire repo
- Integrated into our CI
Signed-off-by: Andrea Luzzardi <aluzzardi@gmail.com>
This will prevent the job waiting on itself to complete (which will not
happen until GitHub Actions kills the run).
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
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>
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>
Because of the mount disjunction, passing a non-concrete #FS results in
CUE being confused as to what type of mount it is (Cache, FS, Secret,
...).
This adds an explicit error check.
Signed-off-by: Andrea Luzzardi <aluzzardi@gmail.com>
