Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a GitHub Workflow that auto-releases regularly #1372

Merged
merged 1 commit into from
Jan 17, 2022
Merged

Add a GitHub Workflow that auto-releases regularly #1372

merged 1 commit into from
Jan 17, 2022

Conversation

gerhard
Copy link
Member

@gerhard gerhard commented Jan 10, 2022

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
Copy link
Member Author

gerhard commented Jan 11, 2022

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member Author

gerhard commented Jan 13, 2022

@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
Copy link
Contributor

samalba commented Jan 13, 2022

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
Copy link
Member Author

gerhard commented Jan 14, 2022

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 gerhard changed the title [draft] Add a GitHub Action that auto-releases every week Add a GitHub Action that auto-releases every week Jan 14, 2022
@gerhard
Copy link
Member Author

gerhard commented Jan 14, 2022

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.
image

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

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

@netlify
Copy link

netlify bot commented Jan 14, 2022

✔️ 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 gerhard changed the title Add a GitHub Action that auto-releases every week Add a GitHub Workflow that auto-releases regularly Jan 14, 2022
…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>
@gerhard
Copy link
Member Author

gerhard commented Jan 14, 2022

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

@gerhard
Copy link
Member Author

gerhard commented Jan 15, 2022

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

@gerhard
Copy link
Member Author

gerhard commented Jan 17, 2022

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

image

@gerhard gerhard merged commit ec3692d into dagger:main Jan 17, 2022
@gerhard gerhard deleted the auto-release-weekly branch January 17, 2022 17:44
@gerhard
Copy link
Member Author

gerhard commented Jan 18, 2022

The workflow was triggered as expected by the cron schedule:

image

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

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:
Screenshot 2022-01-18 at 18 10 38

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
image

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants