https://pantsbuild.org/ logo
Join Slack
Powered by
Hi all! I've filed issue <https://github.com/pants...
# general
b
Hi all! I've filed issue https://github.com/pantsbuild/pants/issues/16494 wrt adding 
--pull=False
to docker CLI when doing 
docker_image
. This will come handy when build process is multi-stage and each target can assume one stage of the building process. Seems like a straightforward change and if we are ok with the idea, I would like to take a stab at adding 
pull
boolean field to 
docker_image
rule. What do you all think?
✅ 1
h
Hi! I'm not a Docker expert, but it makes sense to me. I think it would be helpful in the 
help
message to explain the workflow you're describing
Do you know how to get started on a PR?
b
yup would love to get started and contribute. Will keep in mind the help message part. Thanks!
❤️ 2
h
awesome, we love contributions 💜 don't hesitate to ask for help if you have questions or want early feedback!
👍 1
b
Thank you for contributing!
b
rather than doing this for 
--pull
, should we expose 
extra_build_args
and 
extra_run_args
so that the users can freely specify args? like 
--platform
,
--mount
etc?
h
Hmmmmmmmm, interesting. Maybe? As long as we understand the consequences, since the pants-docker interactions are complicated by the fact that the local docker daemon holds state that pants can’t track.
So it’s a little more tricky to reason about than most other backends.
But I think that should be fine?
c
There's an unfortunate asymmetry between build and run in that build args are a thing in itself and not generic args for the command line so it would be something like —docker-build-cli-args / —docker-run-args.
I'm neutral to adding generic cli args for the build step. Reason being that it is useful to work around missing features in our docker backend but hurtful as it will then require to pass those options via cli or config which may be sub optimal. While having the escape hatch is good for short term progress it may reduce feedback about things we need to address long term.
b
yeah my worry is that we will be playing catch up game forever since docker CLI will evolve in time. It's really hard to capture docker building in a truly hermetic build system. Other build systems like Bazel provide the full escape hatch on that regard (e.g.: https://github.com/bazelbuild/rules_docker/blob/master/docker/util/README.md#container_run_and_commit)
👍 1
c
Indeed, so it may be that the pro’s outweigh the con’s for adding generic build cli args here 🤷 ;) (I didn't analyze deeply hence my neutral stance)
b
To make it as flexible as possible, maybe we provide 
extra_args
, 
extra_run_args
and 
extra_build_args
(or should we call 
package
). extra args will be applied in both run and package, and we have run and package dedicated sets on top of those?
c
Consider which options would be required on the cli rather than passed as env vars, as that is already supported. Things like dockerhost and certificates for docker daemon auth etc may all be set in the env, so no need for supporting them on the cli for instance.
👍 1
b
another possibility is to use docker's own python sdk for build: https://docker-py.readthedocs.io/en/stable/images.html#docker.models.images.ImageCollection.build In an ideal world, we will be pretty much adopting those parameters and let users specify params to get passed through to the sdk call? Well I realize it's a pretty complex topic 🙂 for the initial PR, I'll just add pull as a boolean field for now
👍 1
I opened my first PR 🙂 https://github.com/pantsbuild/pants/pull/16607 When you get the chance, could you take a look at the PR please? It's my first one so they won't run GHA before someone reviewing and unblocking it
🙏 1
❤️ 2
7 Views
Open in Slack
PreviousNext
Powered by