Add a GitHub Workflow that auto-releases regularly

[gerhard]

Talking with @aluzzardi, we think that regular releases which happen with no intervention on our part would be a good idea.

The last Dagger release - v0.1.0-alpha.31 - was over 1 month ago, and there are many Europa-related changes which we want to make available in the Dagger GitHub Action, as well as to users that do not build Dagger locally. The only thing that we need to do is create a new git tag & push. Remembering to do it, and then actually doing it doesn't always happen, and when it does, it's all ad-hoc.

We don't think that there should be 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 at least every Tuesday, 5pm UTC & 9am SFO.

The general consensus is to always be shipping. If we want to release an ad-hoc revision, we can still do it by triggering this GitHub Action manually.

[gerhard]

Agreed in a chat with @aluzzardi:

• Bump the last digit every week. Today that means v0.1.0-alpha.31 -> v0.1.0-alpha.32
• Do not tag if any HEAD check is red -> there is a GitHub Action feature that was recently (@aluzzardi to share the link)
• The Discord update happens asynchronously from this, and is not necessarily tied to a weekly release

We talked with @samalba yesterday about the mailing list update - a.k.a. product update - which happens even less frequently than the Discord one, and is more involved. I am mentioning that for completeness, it's not related to this PR.

---

Something that we did not have time to properly dig into are the release versions. Currently release versions start with 0.1.0-alpha, which is OK.

From a semver perspective, alpha means a pre-release. In my experience, these usually coincide with dev builds, and the expectation is that every commit to the main branch triggers one so that any user can test a specific change in a Dagger dev build which gets produced automatically. In some cases, alpha is replaced with dev, but this breaks semver ordering if beta is used as well.

Continuing the semver idea, beta signals steps towards a release-candidate, or rc. These type of releases fit well into a release schedule or a release calendar, and while this is not a requirement, I do see a strong connection to the weekly releases that this PR is proposing. While I am not suggesting that we take this step now, it is something that we may want to think about.

While the beta releases comments above was a stretch, I know for a fact that discussing rc, patches, minors or majors in this context is well out of scope, so I'm stopping here.

[aluzzardi]

Do not tag if any HEAD check is red -> there is a GitHub Action feature that was recently (@aluzzardi to share the link)

Found it. I'm actually not sure if this could be useful, but there's a primitive to trigger a workflow based on another workflow:

https://docs.github.com/en/actions/learn-github-actions/events-that-trigger-workflows#workflow_run

I'm not sure if we can use this for tagging (since we're using a schedule trigger), but perhaps we could use this on the release workflow (e.g. release workflow only runs if CI workflow is green).

[aluzzardi]

Something that we did not have time to properly dig into are the release versions. Currently release versions start with 0.1.0-alpha, which is OK.

To be discussed, but on top of my head we'll probably release a 0.2.0-alpha.1 at the end of the month and go from there (0.2.0-alpha.2, ...)

Once we're ready to enable Europa by default, we can switch to 0.2.0 and do weekly patch bumps (0.2.1, ...).

/cc @samalba who designed the current release schema

[gerhard]

@talentedmrjones Can we release v0.2.0 on 2/2/22
@TomChv at 2:22:22
@talentedmrjones UTC is fine

I love this idea! Taking it as a follow-up to this action as I am in the only one in the UTC timezone 😃

[samalba]

LGTM.

Just a note: if we are not timely writing the release extract to Discord, it'll be harder and harder to do so (eg. manually extract the generated changelog and post highlights to Discord) - exactly like @jlongtine did it last time on #general. We need an owner for making sure it happens everyweek (cannot be automated), I suggest @jlongtine as a start.

Also: it seems the auto-schedule is disabled in the PR? Is it on purpose to start with manual triggers? I am fine to merge as-is anyhow.

[gerhard]

Just a note: if we are not timely writing the release extract to Discord, it'll be harder and harder to do so (eg. manually extract the generated changelog and post highlights to Discord) - exactly like @jlongtine did it last time on #general. We need an owner for making sure it happens every week (cannot be automated), I suggest @jlongtine as a start.

Yes, agreed. While this is something that we are doing manually for now, there are open-source projects that do this successfully in an automated way. I am leaving this as a follow-up improvement, we can discuss various options then.

Also: it seems the auto-schedule is disabled in the PR? Is it on purpose to start with manual triggers? I am fine to merge as-is anyhow.

This PR is not there yet. I started the conversation early to get an idea for what I was missing, and to share the general direction. I will update when it's ready to merge, thank you for the attention!

[gerhard]

This is now ready to review and merge @samalba @aluzzardi @shykes

I have captured as much as I thought was reasonable in the git commit message.

I ran extensive tests on https://github.com/gerhard/dagger/actions/workflows/trigger-release.yml, you can check them out to see how this behaves in various scenarios.

Oh, and the latest tag of my dagger/dagger fork is v0.2.0 😁

Notice that the tags created by the github-actions user are not verified, which I think is OK.

[netlify]

✔️ Deploy Preview for devel-docs-dagger-io ready!

🔨 Explore the source changes: fcdda0b

🔍 Inspect the deploy log: https://app.netlify.com/sites/devel-docs-dagger-io/deploys/61e1dd03d91a9100087600cb

😎 Browse the preview: https://deploy-preview-1372--devel-docs-dagger-io.netlify.app/reference/argocd

[gerhard]

Rebased on top of main to be sure that everything works as expected 🌊

[gerhard]

If you're happy for this to go in @aluzzardi, please go for that Merge pull request dopamine shot.

[gerhard]

There is no change here which would surprise @aluzzardi, so I am going to be optimistically proactive and merge this.

The assumption is that with this merged, v0.1.0-alpha.33 will be auto-released tomorrow, ~1 week after v0.1.0-alpha.32. It's worth mentioning that we can trigger the workflow manually at any point in time and release a new version with the correct tag bump.

Next step: kick off the release schedule discussion so that we know what happens between v0.1.0-alpha.33 & v0.1.0, and then v0.2.0. I know that @aluzzardi has done a lot of thinking about this already, and other team members have too, so let's take a sitrep and share with the community our thinking -> #1439

---

FWIW, this PR reminds me of a great article which I read some months ago: Ship / Show / Ask

[gerhard]

The workflow was triggered as expected by the cron schedule:

The problem was that on the first attempt, the run failed because GITHUB_TOKEN did not have write permissions:

Having read this GitHub documentation page, it became obvious that we needed to grant Read and write permissions to GitHub Workflows at an organisation level for this to work:

After the new write permissions were applied, the second attempt worked.
Unfortunately the tag was not bumped correctly, v0.1.0-alpha.32 -> 0.1.1-alpha.0

I will iterate on my fork to better understand what happened, then PR the fix once I have it.

For now, I will delete the new tag 0.1.1-alpha.0 and manually trigger v0.1.0, as mentioned here: #1439 (reply in thread)

Q: Why did the new v0.1.1-alpha.0 tag not trigger the Release workflow?
A: #1450 answers this, and also includes a fix.