hitobito / development

Setup your local machine for hitobito development
GNU Affero General Public License v3.0
19 stars 15 forks source link

Ignore changes to Gemfile.lock #12

Closed carlobeltrame closed 3 weeks ago

carlobeltrame commented 3 years ago

It is still a pain point that during startup of the application, the Gemfile.lock of the core is changed depending on the wagons loaded. This PR attempts to remedy this problem, by letting the developer ignore those changes more easily.

This PR provides a Gemfile.lock in this repository, and mounts it over the "real" core Gemfile.lock inside the container. Any changes made by bundle install during app startup will now be done to the new Gemfile.lock in this development repo, and therefore not disturb the git status of the hitobito core.

In case the developer really installed or updated some gems, the Gemfile.lock from the development repository can easily be copied to the core directory (app/hitobito), and checked into Git from there. This is a new manual step, but previously the developer couldn't blindly commit the Gemfile.lock either, but instead already had to carefully separate wagon-related changes from real core-related changes. Since this is a much rarer use case than just running and editing the project without changing dependencies, I decided this change is worth it.

Of course, the changes to Gemfile.lock now pollutes the git status of this development repo, but again, changes to this repository are much rarer than just starting the project and changing something in the core or in a wagon.

In case the Gemfile.lock in the core master branch changes, I also added a GitHub Action that synchronizes those changes to the local one in this repo every night.

Side note about why we don't use tmpfs: For one, tmpfs is only available on Docker for Linux, and this Docker setup has also been used on Mac and Windows. Additionally, based on my attempts (gladly prove me wrong), it is not possible to mount a tmpfs file nested inside a bind mount, because the tmpfs is mounted first.

rnestler commented 3 months ago

Would it be possible to set it up in a way that the combined lock file ends up in the project wagon? So for SAC/CAS in app/hitobito_sac_cas? Also the combined db schema could end up there, which would also ease the setup a lot IMO.

mtnstar commented 3 weeks ago

handled by #73