opensearch-project
Docker based development for Jekyll
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.
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....
@epugh was the --net=host the solution for your use case? You think we should document that pattern?
@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.....
@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.
Thanks for validating the steps, @dtaivpp! Much appreciated. Let's get a review from @AMoo-Miki too (specifically fixing the Ruby version).
@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 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
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 ?