Figure out Dockerization or create a complete Gemfile to be copied in

[raghubetina]

I think we've floated around this idea before, but it feels to me like we really need to get a solid handle on Dockerizing every project precisely, creating a Docker image for every project, pushing the images to Docker hub, and making Gitpod aware of every image. As opposed to trying to use one image for all projects, which then becomes outdated whenever a new gem version comes out and is used by one of us when we generate an app on a different laptop, and then the Gitpod workspace creation process becomes slow again for students.

Do you agree @jelaniwoods? The alternative, as far as I can tell, would be to copy in a Gemfile/Gemfile.lock that has every gem version number exactly specified, down to the minor patch level. For our purposes this would be fine, there's no feature in Rails that we use in AppDev 1 that has changed really since Rails 4 or even Rails 3, that I can think of.

[jelaniwoods]

we really need to get a solid handle on Dockerizing every project precisely, creating a Docker image for every project, pushing the images to Docker hub, and making Gitpod aware of every image.

@raghubetina yes, that is kind of the process I had to go through to make the "instant bundle" docker images work. I ran into some trouble with the base-rails repo because it used webpacker I think? Since it was in a working state and students had already started, I paused my work on it and switched focus to other issues.

The alternative, as far as I can tell, would be to copy in a Gemfile/Gemfile.lock

This was also the approach I was using to Dockerize projects.

[jelaniwoods]

I found this game to help learn Docker that I intend to investigate at some point.

[raghubetina]

@jelaniwoods

This was also the approach I was using to Dockerize projects.

I think there's a subtle difference. What I meant is that we could include in appdev_template a canonical Gemfile with specific, exact versions of every single gem that we would then overwrite the generated Gemfile after rails new and before bundle install.

If we do that then a single Docker image on Docker Hub would be sufficient, because we exactly lock down which versions of gems are ever in use, regardless of who and which machine a project is generated on.

In contrast, we could not lock down gem versions that harshly, and instead Dockerize each project with its own Dockerfile, create its own image, push that image to the Hub, etc.

base-rails repo because it used webpacker

Hm. For everything except base-rails I wanted to get rid of webpacker and go back to sprockets, and get rid of action mailer, action text, action storage, cable, channels, etc etc etc. But I would like to keep webpacker on base-rails since that's what they will be building off of after the course is over, so we should figure out whatever the problem is there.

[raghubetina]

I found this game to help learn Docker that I intend to investigate at some point.

If you like it lmk @jelaniwoods , I'll add it to the RP workshop maybe.

[jelaniwoods]

What I meant is that we could include in appdev_template a canonical Gemfile with specific, exact versions of every single gem that we would then overwrite the generated Gemfile after rails new and before bundle install.

Oh, I see. That should probably work. I was thinking maybe a downside to that approach would be the annoying Github notifications when a deprecation warning happens, but that wouldn't really be solved by having a specific image for each project anyway.