Docker based development for Jekyll

[epugh]

Description

Frustrated with Ruby install issues? Using Docker already? This let's you contribute documentation improvements without installing Ruby locally.

Issues Resolved

List any issues this PR will resolve, e.g. Closes [...].

Checklist

• [ x] By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and subject to the Developers Certificate of Origin.
  For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[Naarcha-AWS]

Love this @epugh! Let me know when it's ready for review.

[dtaivpp]

Ping

[epugh]

Hi all.. So I paired on this with @dtaivpp and I think I have something working. One potentially controversial decision was to lock the version of Ruby to 3.2.4. I polled my local Ruby group on their opinions on if the Gemfile.lock should be checked in and the consensus was that yes, it should be, and yes, you should pick a Ruby and stick with it. By doing this, we don't regenerate the Gemfile.lock constantly, and we can upgrade dependencies more intentionally. I would LOVE to hear if this works properly on a Linux and Window's environments....

[dtaivpp]

@epugh was the --net=host the solution for your use case? You think we should document that pattern?

[epugh]

@epugh was the --net=host the solution for your use case? You think we should document that pattern?

I actually didn't a get chance to try that one.....

[dtaivpp]

Works on Linux but I had a few comments to make it more usable.

[dtaivpp]

Should we move the host and jekyll_env to an env variable? This way we can allow the users to more easily set variables.

ENV JEKYLL_ENV=development
ENV HOST=127.0.0.1

[epugh]

Probably! I haven't actually used ENV much in the past, so it felt "new" to me... ! Please make the change!

[dtaivpp]

The other thing is maybe at the end of this we add config files for overwriting the site.url.

--config _config.yml,_config_docker.yml

When I was testing I found the only way to access the site off my machine was using a _config_docker.yml with the following contents and the JEKYLL_ENV=production.

url: "http://10.0.5.93:4000"

[epugh]

I love it!

[epugh]

should we add a 1 liner description in the CONTRIBUTING.md file ? "To run this on your droplet..."???

[dtaivpp]

100% I'll add that along with a bit more about the pattern.

[dtaivpp]

@kolchfa-aws I reviewed these and confirmed the steps outlined work and are documented correctly!

[Naarcha-AWS]

Test on Windows was successful.

[Naarcha-AWS]

@epugh: Once you take this out of draft mode, I'll give the language and formatting a proper review. Ping me when you're ready.

[epugh]

@Naarcha-AWS it's no longer draft! THanks for testing on windows!

[kolchfa-aws]

Thanks for validating the steps, @dtaivpp! Much appreciated. Let's get a review from @AMoo-Miki too (specifically fixing the Ruby version).

[Naarcha-AWS]

This changes suggested make the formatting more in line with the next section.

[Naarcha-AWS]

@epugh: Per the advice of @AMoo-Miki, the gemfile shouldn't prevent someone from using a different version of ruby if they so choose. One alternative is to make a gemfile specific for Docker.

[hdhalter]

@dtaivpp , @epugh - Is Miki's comment a blocker for pushing this up?

[dtaivpp]

@hdhalter I think that comes down to the preferences of the project. It's pretty standard to standardize on a single version of ruby. That way changes that are made in one persons environment should be guaranteed to work in production with the same ruby version.

@AMoo-Miki I'm curious what advantage there is to allowing users to use any ruby version they'd like. That feels like a risk

[epugh]

Just went to add some docs and ran build.sh and hit the

Could not find jekyll-last-modified-at-1.3.0, i18n-1.14.3, rouge-4.2.0, posix-spawn-0.3.15, public_suffix-5.0.4, concurrent-ruby-1.2.3, sass-embedded-1.71.1-x86_64-darwin, ffi-1.16.3, google-protobuf-3.25.3-x86_64-darwin, rb-inotify-0.10.1 in locally installed gems

message.

The big change that impacts non Docker users in this set up is that we check into the repo Gemfile.lock and specify the version of Ruby to use, instead of leaving it open.... So you have to use a specific Ruby... Though we will then know all the versions of the gems you use ;-). This is my preference.

If that is too much, I could look at having Docker install ruby and the gems at start up time. That would make firing up the docker image a lot slower, but might be a more gentle introduction of Docker into the tool chain.... Thoughts @AMoo-Miki ?

[epugh]

This was solved in #8220! Thanks @hainenber for getting this problem solved!