Revert to Ruby 2.6 for wider compatibility with Jekyll plugins

[elstudio]

Revert to Ruby 2.6, which has the advantage of addressing both of these issues:

• Fixes #25, removing many of the deprecation warnings caused by Ruby 2.7
• Fixes #16, as bundler 1.7.2 is the default version that ships with Ruby 2.6

While there are more flexible ways to address this, at this point GitHub Pages still runs Ruby 2.5 -- so it may be some time that Jekyll plugins are fully happy with 2.7.

Let me know what you think, Alain!

-e

[helaili]

Nice to see you here @elstudio. I don't have any strong feelings about Ruby versions. Any chance this could be a breaking change for existing users of this action?

[elstudio]

Hi @helaili —

The TL;DR: Ruby 2.6 is probably more compatible with more Jekyll plugins (and more Gemfile.lock bundles) than the 2.7 version this action uses currently.

But your question is a good one! And I’m not sure of the best answer.

• This PR simply uses a Ruby 2.6 image, which is a good guess for the moment (more widely compatible with Jekyll plugins than 2.7 right now), but may not work for everybody.
• Systems seem to ship with the Bundler version that was current for the particular version of Ruby. So Alpine with Ruby 2.6 ships with Bundler 1.17, and 2.7 with Bundler 2.1.
• Folks who use modern best practices like rbenv can install multiple Ruby versions with the proper version of Bundler for each. But this is perhaps not common knowledge among those starting out with Jekyll.

The problem is this: when you do a bundle install the version of Bundler gets written into Gemfile.lock — which means that if you committed a lock file written by one version of Bundler, the install using a different Bundler version will conk at the install step.

I don’t know how commonplace it is to have mismatched Ruby and Bundler versions, but Bundler 2.1 will install on older Rubys like 2.6, so it’s possible.

@michaelcurran is working around this by parsing Gemfile.lock directly: https://github.com/helaili/jekyll-action/issues/16#issuecomment-639323754

Longer term though, would it be better to let folks choose their Ruby version by reading .rbenv file or some other means? Maybe. But that’s harder to do with a Docker-based action — especially since the Actions runners already provide a quick install route for different Ruby versions.

A different way to address this is to use the Rubys that are already available on the Actions runner, using the ruby/setup-ruby action in a workflow like this.

- name: 💎 setup ruby
  uses: ruby/setup-ruby@v1
  with:
    ruby-version: 2.6

- name: Jekyll build
  run: |
    bundle install
    bundle exec jekyll build

With this approach, folks who need Ruby 2.7 can just specify it — and they get the proper version of Bundler automagically. And the version is saved in the workflow, version controlled along with Gemfile.lock.

You can see the entire workflow, which includes caching and publishing here: https://github.com/universal-exports-ltd/slide-heroes/blob/master/.github/workflows/jekyll-build.yml.

But this is a completely different architecture than the Docker action you have here.

[helaili]

We actually had a similar architectural discussion in #17 with @limjh16 and it came down to a tradeoff between flexibility, speed and simplicity. It's like the CAP theorem, you can't get all of them. Your run based solution has maximum flexibility, @limjh16's great for speed and this one is just dead simple. I should probably reference your workflow in the documentation in order to provide an alternative path to people with specific needs.

On the Ruby version side, I ran a quick check with my sample site and it did fail, so my thinking is although your change is probably right, I need to find a way to maintain a 2.6 (for new users) and 2.7 (legacy) path.

[Sytten]

@helaili can you at least merge the access token fix its fairly annoying right now if you use GITHUB_TOKEN