https://pantsbuild.org/ logo
Join Slack
Powered by
Is there a way to stop docker from pushing latest,...
# general
a
Is there a way to stop docker from pushing latest, without putting that into tags for each package? The way I read the docs, if I put stuff in extra_tags, those are just added to latest
h
cc @curved-television-6568, I vaguely remember you doing some changes about this?
c
Is there a way to stop docker from pushing latest, without putting that into tags for each package?
Currently there's no easy way to prohibit the push of a specific tag, only all tags per registry. If you describe what you want to achieve I may be able to provide a workable work around. Please feel free to submit a feature request on Github for this in the mean time.
💜 1
a
I haven’t yet managed to get our images to build, so I’m going by what the docs suggest. But what I want is to only tag and push one tag, for every image in the repo. Imagine something like pushing only 
:pr-$PR_NUMBER
. My understanding is that if I do 
extra_tags = ["{build_args.IMAGE_TAG}"]
, that will push that and 
latest
?
c
First, I'm not sure what your 
extra_tags
refers to, as there are only 
image_tags
on the 
docker_image
target and 
extra_image_tags
configuration for the 
docker
subsystem.
a
Sorry, 
extra_image_tags
, yeah.
c
k
Then yes, the default for 
image_tags
is 
["latest"]
, so you'd want to either use a macro to provide your own default (maybe empty list), or (unattractive from your perspective, I realize) bleeding edge where there is a new feature to provide custom default field values using a new 
__defaults__
feature in the BUILD file. As the 
extra_image_tags
adds to any tags provided on the 
docker_image
(including the default)
a
How bleeding edge are we talking? 🙂
h
Pants 2.14 hehe, but we haven't had an alpha or rc release yet, so it's generally not recommended for production
I think this next release should probably be 
a0
, given our release cadence
a
Okay, well, that’s a bit too bleeding edge, yeah. And I have a feeling that if I delay this PR more I’m going to go crazy, spending hours every day fixing merge conflicts/things that other people broke heh.
➕ 1
💯 1
c
It wouldn't be particularly difficult to support something like 
"extra_image_tags = ["!latest", ...]
and backport that to 2.13
h
and backport that to 2.13
We're trying to get out the stable release by end of next week at the latest, so I'm gonna be a party pooper and discourage us from backporting new features. Only backport performance fixes and bug fixes
c
ok 🙂 (for 2.13.x any way, after the stable is out) @ancient-france-42909 so for now, overriding the default 
image_tags
with an empty list seems to be what you want here, and to avoid having to do that for every target, using a macro is likely the best approach (granted, you'd have to change all 
docker_image
targets to your macro version, but from there it would be transparent going forward)
a
I have a script I used to fix other things, modifying the ast in BUILD files, so that shouldn’t be too hard
👍 1
I plan to use it to get rid of the billion “pattern doesn’t match anything” warnings we have too, heh.
h
Another Pants user has had success with Buildozer https://blog.pantsbuild.org/updating-pants-build-files-programmatically/
a
Oh, didn’t know that worked.
Though, in my case, I was splitting python_tests into that and python_test_utils with conftest.py files, so not sure it would’ve been that easy.
👍 1
Since I needed to run code to see if the patterns match any conftest.py files
h
Got it. And sorry for that particular 
python_test_utils
change, I know that was particularly painful 😞 It was a Gedanken bug with our modeling and we spent a lot of time trying to find a workaround. I really wish we got the modeling right in the beginning
a
Yeah, that took me an hour or so to write, but it was definitely not the most frustrating part of this upgrade 🙂
👍 1
4 Views
Open in Slack
PreviousNext
Powered by