Use the same Ruby version in CI and Gemfile.lock

[handshake-enthusiast]

See #165.

[handshake-enthusiast]

Otherwise when a new minor Ruby version is released you may encounter similar problems as before.

[handshake-enthusiast]

Currently:

https://github.com/handshake-org/handshake-org.github.io/actions/runs/4468312416/jobs/7848896393

Downloading Ruby
  https://github.com/ruby/ruby-builder/releases/download/toolcache/ruby-3.2.1-ubuntu-22.04.tar.gz

While the actual Ruby version specified in Gemfile.lock is 3.2.0

[nodech]

If I understood correctly, it will allow minor updates but no major one: 3.x.

I think we should let it break for v3 and do proper version update like in #172.

Allows us to catch any issue with versioning if there's any and update the dependencies. Previously that was also broken, as the constraints on versions were not correct (would allow breaking changes).

If at some point in ruby 3.x totally breaks the builder, then we can specify latest that works.

[handshake-enthusiast]

I changed "Otherwise when a new major Ruby versions is released you may encounter similar problems as before." to "Otherwise when a new minor Ruby version is released you may encounter similar problems as before.". I intended to write "minor", not "major", i.e. when Ruby 3.3.0 is released.

If I understood correctly, it will allow minor updates but no major one: 3.x.

I'm not sure what you mean by "it", but likely you don't understand this change correctly. My patch fixes the Ruby version to exactly one specified and used in Gemfile.lock. "Use the same Ruby version in CI and Gemfile.lock"

I think we should let it break for v3 and do proper version update like in #172.

I don't get why we should let the CI build break.
#172 is not actually a proper update from a Rubyist point of view. Let's start with the first line – ruby '>=3.0.0'. Specifying such a constraint doesn't make really sense in real life. Almost always it's fixed to a specific patch version. I can assume someone may want to let a different patch version be used in some cases, but everything between minor versions is too risky to be breaking. Also I don't think you checked changelogs of updated gems (more an assumption), understand how bundler manages updates (judging on changing in Gemfile) and looked into CI warnings (see "Run ./bin/build") and local warnings. Correct me if I'm wrong.
Also updating to Ruby 3.2.0 while 3.2.1 is available looks a bit strange to me.

Allows us to catch any issue with versioning if there's any and update the dependencies.

There is no issue with versioning when it's done correctly. There is no need to update dependencies generally, you may want to update in case of security issues (we generally don't care because it's in Github CI, not public facing) or some features necessary, or bugs.

Previously that was also broken, as the constraints on versions were not correct (would allow breaking changes).

Why it was broken was explained in #165, see ruby/setup-ruby#442 (comment).

If at some point in ruby 3.x totally breaks the builder, then we can specify latest that works.

Of course, every time the CI build breaks we can update dependencies until the build succeeds (after a couple months may be). Or the build can be written, so it doesn't break.

[nodech]

I agree with the fix of CI build being fixed to gemfile.lock sounds good. Regardless of the Gemfile itself, locking build to lockfile (verified build) sounds reasonable.

ruby '>=3.0.0'

Yeah, this should have been ~> 3.0.0 (Edit is this even a thing?), I fixed others but forgot that line. My assumption is that Ruby uses semver, so I would not expect Ruby itself to break the build.

3.2.0 is not manual, lock file was regenerated with the updated dependencies and I used whatever was installed on the machine. Unless 3.2.x can break the code (which even 3.x should not), general '~>3.0.0` for development machines out there should work.

There were no warnings on build. Only heads up for i18.

[handshake-enthusiast]

Gemfile is just an instruction to install necessary gems. Gemfile.lock is a king, it contains the full list of installed gems with exact versions. Bundler installs gems from Gemfile.lock.

Yeah, this should have been ~> 3.0.0 (Edit is this even a thing?), I fixed others but forgot that line.

~> 3.0.0 would have been equivalent to ['>= 3.0.0', '< 3.1.0'].

My assumption is that Ruby uses semver, so I would not expect Ruby itself to break the build.

Even a patch version could be breaking together with some gems though unlikely. A minor version is likely to be breaking.

3.2.0 is not manual, lock file was regenerated with the updated dependencies and I used whatever was installed on the machine.

Yes, Gemfile.lock just records the installed versions during bundle update. I understand you used Ruby 3.2.0. A bit better option would be to use Ruby 3.2.1 as it's already available.

Unless 3.2.x can break the code (which even 3.x should not), general '~>3.0.0` for development machines out there should work.

3.2.x (i.e. 3.2.0 vs 3.2.Z) shouldn't break the code. In this project ~> 3.2.0 should be fine. It will allow other to use whatever version 3.2.Z they have installed locally. However, I'd use 3.2.1 if this is my choice .

There were no warnings on build. Only heads up for i18.

From https://github.com/handshake-org/handshake-org.github.io/actions/runs/4468355857/jobs/7848999143:

DEPRECATED] The `--path` flag is deprecated because it relies on being remembered across bundler invocations, which bundler will no longer do in future versions. Instead please use `bundle config set --local path '../../build/vendor'`, and stop using this flag
Bundler 2.4.6 is running, but your lockfile was generated with 2.4.1. Installing Bundler 2.4.1 and restarting using that version.
...
[DEPRECATED] The `--path` flag is deprecated because it relies on being remembered across bundler invocations, which bundler will no longer do in future versions. Instead please use `bundle config set --local path '../../build/vendor'`, and stop using this flag
...
/home/runner/work/handshake-org.github.io/handshake-org.github.io/build/vendor/ruby/3.2.0/gems/tilt-2.0.11/lib/tilt/redcarpet.rb:64: warning: undefining the allocator of T_DATA class Redcarpet::Markdown

Fixed in #174.