New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using buildx #76
Comments
Hey! It's possible to use buildx right now, if you set it as a default builder. Here is an example Github Action which uses buildx and its caching capabilities: https://github.com/anycable/anycable_rails_demo/pull/25/files#diff-28802fbf11c83a2eee09623fb192785e7ca92a3f40602a517c011b947a1822d3R28-R44 |
I was just looking for something like the Thanks so much for the handy references 👍 I'm following along now to see if they get me across the line! I was definitely also missing the default builder feature of setup-buildx-action ( It seems to be working now! I just saw an app image build complete in less than 10 seconds. There are other problems I'm having now, possibly a regression that I found where RAILS_MASTER_KEY is not being exported properly, but I'm going to go and read the source to find out now. If I use the |
With the example in: I can use buildx, so this issue can be closed. |
This is really cool, thanks for figuring the buildx stuff out! I was under the impression you could set an environment variable and it would Just Work™, is that what that |
Yes, it's possible (and that's what |
Alright, if |
I was trying to add support for invoking
docker build
asdocker buildx build
but I'm afraid it might be a little more complicated than thatMy intention is to add these type of params:
https://github.com/fluxcd/image-reflector-controller/blob/62c06ea58cd14072fde2c9ada7c6970dedf580e5/.github/workflows/build.yaml#L57-L59
Then we can cache Docker build layers in a more efficient way. Anyway the
--cache-to
and--cache-from
options are only available in Docker Buildx, like a lot of other options that I'd maybe like to useIn the past I've successfully enabled cache volumes for bundler inside of a Dockerfile, so that changes to the Gemfile and Gemfile.lock would not result in a complete recalculation of the image's build-time dependencies, but would instead build from cache so that only new dependencies were recalculated.
While this is obviously a niche optimization, there are other more common use cases that can only be handled well with buildx. The buildkit toolset is becoming pretty standard now IMHO. I'd love it if it were possible to invoke Kuby build in a way that uses buildx!
I might try implementing this again later, it might be easier now that 0.15.0 is solidly released. In the meanwhile, there is a functioning example of GitHub Actions that is WIP but currently looking pretty good at: https://github.com/kingdonb/kuby_test
With caching properly configured in this one last place, and a couple of other changes, I think this is nearly ready to tag and make an example out of it for contribution back to kuby-core, or to live somewhere in the getkuby project 👍
The text was updated successfully, but these errors were encountered: