Ensure that RAILS_MASTER_KEY is available at assets precompiling time

[kingdonb]

When following the advice that I got here:

• Using buildx #76 (comment)

I decided to split my build for app and assets this way: kuby build --only app and kuby build --only assets so that I could accommodate the use of buildx for caching, which requires each image built to be assigned a separate caching scope... (otherwise, the act of serially building "app" and "assets" is problematic in some subtle ways, that are worth documenting... suffice it to say the "assets" image shadowing the "app" image cache appears to very nearly nuke the cache each time, but with them split properly the caching is very effective!)

Anyway, I found that RAILS_MASTER_KEY was not being passed in build_args anymore, when the assets image is built by itself. With some strategically placed binding.pry statements and inspections of caller I was able to trace the execution – it looks like this (borrowed from lib/kuby/docker/app_image.rb) needs to be included here?

I noticed that you added type signatures in some of the files, but not this one. I would love to learn to use sorbet and I'm happy to take feedback on this PR, if there's something you'd like me to add before merging this.

I'm certainly willing to change it however you want! I'm using this in my test app now, from the master branch of my own fork, (so there's no rush to merge this and get a release out on my account.)

[kingdonb]

This change works for me! I now have end to end from "git push" to rails app deployed just over 3 minutes with caching:

• https://github.com/kingdonb/kuby_test

There is the beginnings of a doc here for it. I'll add an Apache license as well and looking forward to your feedback about it!

[camertron]

Hey @kingdonb, thanks for pointing this out. I was wondering why the integration test hadn't caught this, but then I realized RAILS_MASTER_KEY is set by actions and available to any command when the test runs. This is contrary to what the docs say and how I would think most people would run kuby build, i.e. by setting RAILS_MASTER_KEY per-command.

Given the confusion and number of problems the master key has caused thus far, I'm thinking of making it a bona-fide Kuby argument, eg. kuby build -e production -k <key>. It would probably also make sense to provide a way to opt out, maybe with --skip-key. Thoughts?

I'm glad to hear you've gotten everything working, that's awesome! 🎉 I took a cursory look at kingdonb/kuby_test, but unfortunately my free time is extremely limited right now (I'm actually on paternity leave at the moment 😅) I should have a bit more time in the new year. What you've done looks very promising!

[camertron]

Oh, and one last thing. It looks like the integration test hasn't been running for pull requests. I think the problems are fixed now, so if you merge/rebase master, they should start running (and hopefully passing).

[yebyen]

Congratulations and good vibes to you and your child!

I was definitely exporting the master key, an argument would work fine for me, but I spent a while working on dockerfiles for Rails and don't know how you could skip the master key. Precompiling assets invokes initializers, and I'm pretty sure that's where the master key requirement gets invoked from. (This is @kingdonb on mobile)

[kingdonb]

This issue specifically impacted only the kuby -e production build --only assets usage

In our project, we went to some lengths to make it easy for people to add their Personal Access Token:
fluxcd/flux2#2038

That would be overkill, but we did get reports from some people that command line arguments for secrets are an anti-pattern, as they can be recovered not only from shell history, but also from the linux proc filesystem via ps -a.

We wound up preferring environment variables and/or taking as a stream from STDIN when secrets are missing at runtime.

[kingdonb]

I wanted to share this recording with you, https://youtu.be/HgBdWbYJi1c (there is no audio)

It says "5 minute demo" but honestly the first 2 and a half minutes are just me fixing a bug in my app, then it gets started.

The details of the github caching are probably not interesting to hardly anyone, but the results so far are pretty solid! I settled on using the GitHub caching service, which is almost as good as it gets. Builds complete in less than about 2 minutes when there are no bundle updates, and deployment happens instantaneously, with not much longer than 30s later before Kubernetes starts terminating the old deployment pods.

Please enjoy your leave! But if you're dying to catch up on what I've been doing, this recording might help it along :)

[camertron]

Super cool @kingdonb, the video was fun to watch! I think this all could make a good blog post too if you've got a blog :)