jeklibot#1
Open
jackass0528 wants to merge 5700 commits intocebufooddroid:masterfrom
Open
Conversation
Merge pull request 9305
Merge pull request 9304
This reverts commit 73fcc42.
Merge pull request 9292
Merge pull request 9326
To appease RuboCop `Minitest/AssertInstanceOf`
Merge pull request 9360
…n list (#9376) Merge pull request 9376
Merge pull request 9361
Merge pull request 9401
Merge pull request 9405
Merge pull request 9406
…icle (#9411) Merge pull request 9411
Merge pull request 9392
Merge pull request 9832
Merge pull request 9850
Merge pull request 9867
Merge pull request 9882
Merge pull request 9889
… limit parameters (#9912) Merge pull request 9912
Merge pull request 9897
Merge pull request 9923
Merge pull request 9920
Merge pull request 9914
Merge pull request 9925
Merge pull request 9954
Merge pull request 9960
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-please`](https://github.com/googleapis/release-please-action) action 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 rename `History.markdown` to `CHANGELOG.md` since that's what `release-please` works 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 and `release-please` uses 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 release-please will take care of that when we cut the release. 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: - Merge the docs PR - Merge the automatically generated release-please PR, which will trigger the workflows to do the tagging, releasing, gem publishing, etc. ### Remaining work to do: - [x] Change the pull request settings to only allow squash merges, as jekyllbot enforces this for us today. - [x] ~Update the site publishing process to pull from `CHANGELOG.md` instead of `History.markdown`~ No longer needed. - [x] Integrate jekyllbot into release-please (the release-please PRs will be made by jekyllbot). This allows actions to be triggered on the release-please PRs. - [x] Test the workflows to make sure they generate a PR correctly. - [x] ~Integrate the release publishing workflow into release-please when it creates a release.~ Happens automatically with the existing workflows.
This is a 🐛 bug fix. ## Summary The `release-please.yml` workflow doesn't make sense in forked repositories. Let's restrict its execution to jekyll/jekyll only. I did not expect a "workflow failed" notification soon after catching up with the upstream in my forked repo: <img width="1542" height="961" alt="image" src="https://github.com/user-attachments/assets/5049f2ca-1b1b-42b8-b6ea-4c91ce66a6c3" />
This is a 🔦 documentation change. ## Summary The install documentation for WSL offers to install Ruby through BrightBox. However, BrightBox does not support Ubuntu Jammy (which is the default for latest WSL builds). Instead, this commit just redirects the WSL user to the Ubuntu installation procedure to avoid duplicate documentation.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
18 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.