Golint is replaced with revive since the former has been archived and
replaced with the latter.
Signed-off-by: Marcos Lilljedahl <marcosnils@gmail.com>
The todoapp example contains a Netlify plan which uses the latest dagger
additions: do & Client API. We are thinking of merging the examples
repository into this one to make working with this easier. This is a
step in that direction.
We are not using the yarn package so that we can revert
https://github.com/dagger/dagger/pull/1673 without breaking this
implementation.
The GitHub Action is WIP, we will continue with that tomorrow:
https://github.com/dagger/dagger-for-github/issues/24
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
This was set temporarily 4h later than originally intended so that it
would go through the day that we expected it to. Now that we know it
worked, let's restore it back to the time that matches morning in SFO &
early evening in Europe.
I see no reason to create extra PR work, shipping it straight into main.
FTR, this changes a single value, 21 -> 17, and a few comments.
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
I had to re-run all jobs in the CI workflow at least 10 times in the
past 2 days. The problem is that when one jobs fails, all jobs need to
re-run, which sometimes results in different jobs failing. It would be
great if we could only re-run the jobs that failed, rather than all the
jobs in the CI workflow. Going forward, we should focus on improving
flaky tests, and speed the jobs which take the longest, but for now this
is a good start.
Before this change, we were wasting a lot of dev time - 2h in total for
my last PR #1476 - but also wasting CI minutes. Some of us were even
tempted to ignore CI 😱. This is a very slipper slope, and while it may
feel liberating in the short-term, there are many "windmill monsters"
down this path - don't do it.
Have a look at the CI workflow before this change to see how many
failures we had:
https://github.com/dagger/dagger/actions/workflows/ci.yml
Without looking at the jobs that failed, can you guess which areas are
the flakiest and need our attention the most? Integration & Universe are
good guesses, and I wish we could see this without digging into the CI
workflow - this change does that.
There is a lot more that can be improved here, but I didn't want to get
too carried away. The biggest improvement that we can make is switch
this to Dagger, which has some challenges, but I definitely intend to
tackle them because it feels worth it. This is good enough for now.
This is a ship & show PR. If all tests pass, this is a straight merge. I
am keeping it atomic so that we can revert it if we don't like it.
cc @aluzzardi @talentedmrjones @jlongtine @samalba @shykes @grouville
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
Last time this ran, GoReleaser built an artefact with the wrong version
- it didn't bump it correctly. It was meant to build 0.1.0-alpha.33, but
it built 0.1.0-alpha.32 instead:
https://github.com/dagger/dagger/runs/4860126130?check_suite_focus=true#step:7:94
This new approach is a simpler and more explicit tag bump by leveraging
the semver-tool directly. A link to this utility is included in the
comments. We version it in this repository so that it is all
self-contained.
We also use the gh CLI tool directly, instead of a GitHub Action that
hides the implementation detail behind Typescript. We now have two very
simple gh CLI invocations that do all that. While we still use the
https://github.com/lewagon/wait-on-check-action GitHub Action to wait
on running checks, and abort if any check failed, I didn't want to
bundle that improvement into this PR - it's already big enough.
As a meaningful improvement, we should have a Dagger package that bumps
versions. It would have been so much easier to use that Dagger package.
That implies us switching our GitHub Actions to Dagger, which we should
totally do. Small steps ftw!
Next step: run 0.1.0 release manually
Step 2: run 0.2.0-alpha.1 release manually
Step 3: wait for 0.2.0-alpha.2 to be produced automatically, tomorrow.
Pair: @aluzzardi
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
- 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>
