-
Notifications
You must be signed in to change notification settings - Fork 12
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
Add up/down/pull commands #49
Conversation
Signed-off-by: Eugén Cowie <[email protected]>
Signed-off-by: Eugén Cowie <[email protected]>
Signed-off-by: Eugén Cowie <[email protected]>
Signed-off-by: Eugén Cowie <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR, I will take a close look soon. But I have added a few small commets
Apply suggestions from code review. Co-authored-by: Kim Christensen <[email protected]> Signed-off-by: Eugén Cowie <[email protected]>
0d1b0a8
to
a44ca5c
Compare
We should probably be doing the compose pull during build instead of action runtime so that all of the image dependencies are built into the porter bundle. I know this requires DinD so I need to see if it expects the images to be in the host systems docker cache or if it can use the bundle images docker cache to see if it would even honor pulling images at build time |
Would that be resolved by #26? |
I think partially although the docker-compose mixin build should be collecting those image at bundle build time and it's not. That's a secondary issue that we should also be addressing. I think this PR is good for now but I'm going to open an issue specifically for the build as running a "docker compose pull" at bundle runtime kind of defeats the purpose of CNAB. |
What does this change?
Initial design and structure for adding docker-compose commands as first-class fields. This PR includes pull/up/down as proof of concept, but this can easily be extended to other commands in a follow-on PR.
These commands use the same YAML syntax as the main
docker-compose
field for defining arguments and flags. For example:This is equivalent to
docker-compose --file compose.yml pull --ignore-pull-failures serviceA serviceB
.However, custom fields for each command could be added in the future (with appropriate defaults) without breaking backwards compatibility, allowing for a more concise and natural syntax as suggested in #3 (comment)
What issue does it fix?
Partially implements #3, though more work is needed to flesh it out.
Notes for the reviewer
This is not a breaking change, the existing mixin syntax can still be used and works as expected.
I've updated the tests and examples to use the new syntax.
Checklist