Confusion on whether to use this versus custom workflow

[KonradHoeffner]

In the past I was using another Docker based Jekyll action https://github.com/helaili/jekyll-action [1].
However this recently stopped working and that action was deprecated with the notice remarking that using Docker for Jekyll is bad and should be avoided [2].
After much research and troubleshooting, I finally arrived at a working solution [3] but then I found this action which is described as "part of the official support", however it uses a Docker based action again, which I just moved away from because it should not be used according to https://github.com/helaili/jekyll-action.

Now I'm thoroughly confused: who is right now? Should I stick with the custom workflow [3] or adopt the official solution even though it uses a Docker based action that is supposed to be slow, hard to debug and not reproducible?

[1] Like this:

  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/cache@v3
        with:
          path: vendor/bundle
          key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile') }}
          restore-keys: |
            ${{ runner.os }}-gems-
      - uses: helaili/jekyll-action@v2
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          target_branch: 'static'

[2]

GitHub has a new way to publish a static site to Pages using GitHub Actions. This means you can now build with the Jekyll command (or something else) and use actions to publish, all using regular steps. This removes the need for Docker based actions and gives you all the freedom to configure the execution environment (versions of Ruby, extra dependencies...), it is a lot faster, easier to debug and closer to what you can run on your local machine.

[3]

name: Build and deploy Jekyll site to GitHub Pages

on:
  workflow_dispatch:
  push:
    branches:
      - master
permissions:
  contents: read
  pages: write
  id-token: write

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: '3'
          bundler-cache: true  # runs 'bundle install' and caches installed gems automatically
      - uses: actions/configure-pages@v5 
      - run: bundle exec jekyll build
      - uses: actions/upload-pages-artifact@v3

  deploy:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - uses: actions/deploy-pages@v4

[KonradHoeffner]

P.S.: I also noted that all those new ways do not seem to upload those files to a branch, like "static" or "gh-pages", but instead seems to skip such a branch completely, is that correct? In that case it would not work for my use case, because the github-pages site is just used for testing, while we checkout this branch on the web server for production after verifying with the github-pages site.

[janbrasna]

The "new" examples do not write built sites to any git tree, they just deploy straight to the environment. It can be tweaked to actually commit to git, though, but it's not very usual these days so you'd have to adjust it yourself.

[janbrasna]

What is the difference between:

1. ruby/setup-ruby && bundle exec jekyll build
   vs.
2. actions/jekyll-build-pages ?

The entrypoint.sh says:

"Calls github-pages executable to build the site using allowed plugins and supported configuration"

which aligns with the previous setup, where you rely on github/pages-gem and can only use whitelisted plugins, themes etc.

Whereas if you set up any ruby env and build your Jekyll independent of what usually were the GH restrictions for implicit builds (that used to build on a separate worker independent of GitHub Actions), you can build whatever you want in any configuration you need.