I’ll give more context below, but the simple answer is is that you shouldn’t be hard coding them. They get set as a part of the ondemand SCL so you should be able to pass them through like you do with PATH and LD_LIBRARY_PATH and all the others.
In 1.6 every app had it’s own relative vendor/bundle directory where gems where installed in.
Now we’re trying to optimize so install gems in a central location so all the apps can use the same gems and we don’t need to duplicate them.
GEM_HOME looks to be ruby version specific. When we update ruby versions, you’ll likely need to update this. GEM_PATH has the OOD version in it (1.7.6) so this will have to be updated every time. If you hard coded them, which you shouldn’t need to.
By the time you’re reading sys/dashboard/.env.production your application has already booted and that’s too late. GEM_PATH related variables have to be populated correctly used during boot, i.e., for the app to fully boot up it has to find all the gems it needs.
The BUNDLE_HOME bit was a mistake on my part, I was actually thinking about BUNDLE_USER_CONFIG. We now set this to /dev/null by default in the nginx stage, but I don’t think you need set it or to pass it through here because the bundler default is what we’re overriding. So there’s nothing to be done there.