-
Notifications
You must be signed in to change notification settings - Fork 61
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
cli: engine-agnostic way of building images #907
Comments
@wtraylor any feedback on the above would be greatly appreciated 🙏 |
Thank you, @ivotron, for asking for feedback. I have looked a bit at the Docker Compose syntax, but I have no practical experience with it. The guiding question should be: What do users really need? What missing feature would force them to drop Popper and write everything manually? It the same time, you shouldn’t focus on those 80% of features that will rarely get used. For my current project, I have no need for a more elaborate syntax for building images. The only issue I have is that the docker network bridge doesn’t work on my system, so I need to use So, my 2 cents are to first create a sharp focus on the core features and get all of them really easy to use (with fixing bugs, adding help messages, providing examples, writing tutorials, etc.). Once there is a larger user base, the specific needs of the community will become more apparent. |
thanks a lot for the feedback @wtraylor! I agree 100% on the 80-20 rule. I should have specified that this The main rationale behind this is that in some cases there is the need to build and push images as part of the workflow, for example:
the above doesn't run in singularity or podman, thus making the workflow not portable. The |
high-level outline of how this would be implemented:
cc: @BrayanDurazo |
@jaimistry12 sounds good. Let us know if y'all have any questions, we'll be happy to help. |
Proposal to add an
image
attribute for steps that can be used instead of theuses
one, with the following:The above is inspired by docker-compose's syntax. The goal is to have an engine-independent way of specifying how to build images.
The text was updated successfully, but these errors were encountered: