You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're using fig for development of our entire application, currently consisting of about 20 individual docker containers. This works great, but it takes for ages to build and some of our developers only work on a small subset of the services.
My proposition would be something along the lines of allowing to set both image and build on the same service. If you just need the service running locally, you could use the pre-built docker container defined in image and run that. If you're actively developing a service, you'd check out the source and build the container from the latest source locally by using build.
The text was updated successfully, but these errors were encountered:
This is a very similar to the problem I'm trying to solve with #318.
I don't think including both an image and build on the same service is a good path. It makes it less clear what is which is used (and including both is an error right now, so it's not backwards compatible in any way. Instead I've proposed tagging built images using #457.
To accomplish the setup you describe with these two additions, each service would create a local fig.yml that only knew about the service itself and it's immediate dependencies.
When a developer uses the local fig.yml it will use the build directive for the service, but any service from an "included external project" from #318 would use a tagged image.
This will probably also benefit from #467 to push the latest tags for each service to a registry (unless all development happens on a single machine).
Note: needs a better title
We're using fig for development of our entire application, currently consisting of about 20 individual docker containers. This works great, but it takes for ages to build and some of our developers only work on a small subset of the services.
My proposition would be something along the lines of allowing to set both
image
andbuild
on the same service. If you just need the service running locally, you could use the pre-built docker container defined inimage
and run that. If you're actively developing a service, you'd check out the source and build the container from the latest source locally by usingbuild
.The text was updated successfully, but these errors were encountered: