Support for multiple [Docker] build contexts?

[kyleatcausadix]

Multiple build contexts have been supported by BuildKit (and build, buildx build, Compose, and buildx bake) for over a year now (May 2023)

Any chance we can get these supported by flyctl / fly.toml?

Additional (read: configurable) build contexts are invaluable for monorepos and dependency (supply chain) control. They make it easier to keep cruft out of images, enable more-granular and configurable control of dependencies, lower the complexity of implementing multi-environment deployments, and more.

I know Fly is in a precarious spot playing middleman with abstractions and wrappers around BuildKit, and I’m sure y’all aren’t excited about the prospect of having to thread even more Docker-specific configuration through Viper.

That said, I do hope you’ll consider this. Build context control is a good unlock for users. I also imagine it fits (at least loosely) into Fly’s desire to better support multi-image deployments.

tl;dr, this would be great:

flyctl deploy \
  --build-context frontend=../frontend \
  --build-context api=../api \
  --build-context artifacts=./dist

[build]
  [[build.context]]
  name = 'frontend'
  value = '../frontend'

  [[build.context]]
  name = 'api'
  value = '../api'

  [[build.context]]
  name = 'artifacts'
  value = './dist'

[kyleatcausadix]

For those following along, do note that you can do this without flyctl; it’s just more work.

1. Build your container image locally using build / buildx / buildx bake / compose build
2. Push the image to your Fly registry repo yourself fly auth docker + docker push
3. Deploy that image fly deploy --image registry.fly.io/foo-bar-baz:yourimagetag

[kurt]

I’m not opposed to support for build contexts, but I doubt we’ll get to them anytime soon. If you feel like hacking up a flyctl PR, though, we’d consider merging it.