feat!: Streamline the release process for Jekyll #9760
Conversation
|
Hello Matt, I have not yet completely processed this proposal but I would like to leave a few comments based on superficial understanding:
P.S. Renaming
I am quite surprised by this perspective. Could you please elaborate on why you feel so and how those branches should have been maintained? |
Parts of all of that are true. I'd like to see us release more frequently. I'd like users to have more visibility into what the next release might be and have a central place to talk about why we haven't released yet. As a maintainer, I'd like to not have to think about what the next release might be, when with a small set of tweaks, the computer can do that for me. I think the structure of the history / changelog is fine. I do want better management of it, which I feel like release-please gives us by using the PR to update the changelog rather than jekyllbot coming through and updating it after every single merge.
release-please, both the CLI and the action, are open-source under the Apache 2.0 license. I don't see a reason to keep maintaining our own code for this when it can be replaced by code someone else maintains that is also open source. This feels similar to saying that you have to write your own http client because you don't want to use a third-party library because you don't like their API. Re: upgrading jekyllbot, i'll address that next.
That is exactly right. When the platform offers features that are just as good or better than maintaining our own code for something, I'm going to go with the platform every single time. The
I can keep the labelling. That's not a problem. It will be inferred from the PR title via conventional commits though.
This is a good idea. I'll do more experimentation and implementation there before coming back to update this PR.
This is based on the fact that 4.4.0 contains double the number of bugfixes in the 4.3.x release series. Not to mention the toil of having to backport fixes and run releases for stable branches. Maintaining stable branches is extra work. If we don't violate semver in minor versions, why should we try so hard to maintain them? |
Not a strong argument in favour of my comment about having to play by their rules, but we need not have to switch to enforcing Conventional Commits if JekyllBot would be able to replicate the end-result of
The downside I see regarding this is the time taken for GitHub Actions to execute the workflow (download action code > repository checkout > install dependencies > Run action) in contrast to JekyllBot finishing the action as soon as the underlying webhook is dispatched. But yes, it's just a matter of getting used to the new normal.
The reason for this is that there weren't enough changes to warrant shipping a 4.4.0 at the time 4.3.2 - 4.3.4 were shipped, at the same time
Sometimes UX-critical patches are merged only after the |
As part of jekyll/jekyll#9760, I'm using this repo as a testbed for streamlining automation. The first step is to lint PR titles against the conventional commit spec so that the release-please automation can do its work.
|
Going to dump updates here as I work on this: Enforcing conventional commits at the PR level looks like so when the check fails: It goes green if the format is correct (obviously 😄 ) |
|
jekyll/jekyll-test-gem-plugin#8 has an example of the release-please workflow running. We can keep the existing |
We can keep the `History.markdown` file after all, if we're ok with the small format differences. This reverts commit f15a991.
Taking the lessons learned from doing this several times recently, here are some changes/enhancements: - Keep History.markdown, as we can still use it. - Configure release-please via JSON, hiding the config away in the .github directory - Configure the release manifest so that release-please will pick the next best current release. release-please uses this for its own internal bookkeeping as well. - Remove a bunch of cruft from the workflow file that isn't needed. We don't need to check out the repo or set up node. Just run the release-please action with the correct configuration.
For documentation / record purposes, could you please list all the changes? (This will help refactoring / altering our rake task used to generate |
|
Suggestions / Requests:
|
I'm curious about this one. Why is that important to you?
AFAIK, that's not possible because of release-please's reliance on conventional commits. It won't know how to treat the release PR.
Just to clarify, you want to see If so, yeah, I can do that. Not particularly hung up on the names here.
hahahahaha, sure. i like that better. It's like there's some exasperation or something to go along with it. |
Not Important per se. I prefer having things organized into folders if those things share a singular yet common purpose.
That's exactly the intention. Maintain existing pattern for release commits and simultaneously have it excluded from being logged as a
Yes, that's correct.
😆 |
This is a 🙋 feature or enhancement.
This is a 🔨 code refactoring.
Summary
Improve and streamline our release processes with some extra automation and a bit more rigor around PRs/commits.
Context
With Jekyll 4.4 released, and under the assumption that the next release will indeed be 5.0, I think it makes a lot of sense to take some time and evaluate our development practices and streamline the process of shipping. We generally go a long time (four months between 4.3.4 and 4.4.0, two years between 4.3.0 and 4.4.0) between releases and this is my attempt at trying to improve that. While this PR is currently incomplete, if there's interest in going this direction, I'll make time over the next few days to clean it up and get it ready to actually ship.
In order to do this, I'm relying on the
release-pleaseaction from Google to do the majority of the heavy lifting. Please read the release-please README in order to learn how release-please works and what it does. In order to make it easier to adopt release-please, I've made two additional changes. The first is to renameHistory.markdowntoCHANGELOG.mdsince that's whatrelease-pleaseworks with out of the box. The other is to add two new github actions workflows to run release-please and to enforce conventional commit conventions on PR titles. Because we squash merge, the PR title becomes the commit message andrelease-pleaseuses the commit messages to know when to bump the version number.One potential caveat with this is that it may become harder to maintain stable branches. My point of view on this is that we've done a relatively poor job of maintaining them regardless and I think it's more important to release often, even if we end up bumping major or minor version numbers more frequently than before. My stance on this is that version bumps have no inherent goodness or badness. They are a communication mechanism. We should let go of having to wait a certain amount of time to do major version bumps or avoid work because it would cause a major version bump, for example.
Process changes
The use of release-please means that we can stop using jekyllbot to do the merges and update History.markdown for us, as it will take care of that. We will also no longer need labels on PRs as the use of conventional commits will explain exactly what is changing.
The process for releasing becomes:
Remaining work to do:
Update the site publishing process to pull fromNo longer needed.CHANGELOG.mdinstead ofHistory.markdownIntegrate the release publishing workflow into release-please when it creates a release.Happens automatically with the existing workflows.