I understand that this is still a WIP, but could I ask you to change the trigger to contain string"*-stable" instead of regex/*-stable/. The reasoning here is to avoid triggering a run when the branch is named say2.3-stable-ci-fix. The run is to be triggered when a PR is subsequently opened against2.3-stable.

Also, I wonder why Ruby versions 3.0 and above are quoted entries but 2.7 is numeric. The quote is actually needed only for3.0 because YAML parses it as literal3. Let's quote 'em all for consistency.

FYI: I'm willing to transferashmaroli/release-gem to Jekyll org if need be. To me, it is development-complete.

So far, I have gotten this to a "good enough" state. I think I'll leave it so that one could manually run it, but not that it will automatically run. I ran into too many issues with it, for example jemoji has customizations to the ci.yaml.

One goal of this is to ensure these configs/workflows exist. This creates PRs for everything which allows us to edit and tweak before we merge.

Another goal is to keep our Ruby versions in line. An alternative to the update-the-workflow-directly approach is to get a list of Ruby versions from another Action, like this:ruby/bigdecimal#251. It pulls versions fromruby/actions/.github/workflows/ruby_versions.yml@master, outputs them from one job, and adds them to the next. It seems straightforward. The upsides are that we stop managing these manually, but the downsides are that we (1) don't have control, and (2) lose CI builds for explicitly adding a Ruby version, which (3) causes a contributor to bear the brunt of a new minor Ruby version around the December holidays instead of us tackling that support separately.

One way around the downsides are to use our own versioned yml file which we add the new minor version to each year and then bump the version. For example, last year, we could have been using v1 for pre-Ruby 3.2, then we add 3.2 and release it as v2. Thanks to dependabot'sgithub-actions updates, weshould get the version upgrade as a separate PR (in our example, it would bumpjekyll/actions/.github/workflows/ruby_versions.yml@v1 to@v2). Then we can maintain our supported versions all in one place without having to manage the actual CI job.

I vote for having manual control on Ruby versions per repository.
Theci.yaml generated from this exercise includes testing onwindows-latest whereas traditionally it was handled by AppVeyor.

I left it delegated to AppVeyor instead of migrating to GH Actions because:

• Ruby on Windows (RubyInstaller 2) has a slightly delayed release cycle compared toruby-build packages.
• Reduced noise in GH Action job labels / summary:
  • Continuous Integration (Ruby 3.2) is simpler thanContinuous Integration (Ruby 3.2, ubuntu-latest).
  • Windows-tests arecontiguously located in a separate location --- allowing compartmentalization of test reports for the two main platforms.
• Windows-support is principally second-class in comparison to Linux and macOS.

I left it delegated to AppVeyor

Only 6 repos have AppVeyor enabled/configured:https://dashboard.jekyllrb.com/. We could update this script to manage the appveyor.yml config too if you'd like.

Windows-support is principally second-class in comparison to Linux and macOS.

An artifact of history, not really intentional. This has historically caused us issues, since Windows is the dominant OS in the world. I'm a big proponent in continuing to test Windows since it's a very important development platform.

Ruby on Windows (RubyInstaller 2) has a slightly delayed release cycle compared toruby-build packages.

Is this what AppVeyor uses? Why not use ruby-build? Is the RubyInstaller package more supported/used in the Windows community?

I like Windows on GitHub Actions for a few reasons:

• Developers on GitHub usually know how to use Actions these days
• It's yet another config file to maintain
• AppVeyor builds are slower than Actions builds in my experience, slowing down response times to contributors
• I have historically had issues debugging AppVeyor failures since it's a semi-unknown environment
• If one job fails, the other jobs (versions) do not run

If you prefer AppVeyor, I'm more than happy to stick with them and add the appveyor.yml to this little binary to get it up on more repos. Since I was already working on adding Actions, I figured I'd add windows too. Just let me know and I can removewindows-latest from the ci job.

An artifact of history, not really intentional. 

Glad to hear that. Unfortunately elsewhere, Ruby on Windows (RoW) is still behind Unix-based platforms. I am yet to see articles mentioning "using YJIT with Ruby 3.2 on Windows" ..

Is this what AppVeyor uses? Why not use ruby-build? Is the RubyInstaller package more supported/used in the Windows community?

Both GH Actionruby/setup-ruby andAppVeyor uses RubyInstaller (RI).ruby-builder binaries for non-Windows Ruby are managed by theruby/setup-ruby folks itself and will always be faster than RI (very slight delay, albeit third-party..). RI builds are the goto source for RoW. The other sources documented in Jekyll docs have lesser consumers.

RoW isslower irrespective of CI platform. Honestly, I am not a fan of AppVeyor (compared to GHA) but am sticking with it (esp. forjekyll/jekyll) because:

• PR commit statuses and CI Workflow lists are not littered with interspersed reports of those on Windows. The many runs are collectively located at a different location.
• Windows-based tests can be atomically disabled by having[skip appveyor] in the commit message. (Useful when pushing documentation changes tomaster; having[skip ci] disables GHA as well which is necessary for build+deployment togh-pages branch).

(Hopefully), once GHA provide us with greater control via (collapsible) commit statuses and workflow listings, I will migrate from AppVeyor.