-
Notifications
You must be signed in to change notification settings - Fork 693
Stamp for docker_push? #54
Comments
@samuraisam Hopefully my PR addresses what you're looking for? |
Based on the test in your PR this looks like it would work for my use case above other than still needing to hardcode the repository (eg |
@ixdy is a bit more familiar than I am with manipulating the workspace status stuff, so perhaps he has a suggestion? |
the test in the PR didn't cover it, but I just tested manually where I used |
Neato, thanks! Is there a way to get this to work without a bazel clean between builds, or is that not the way stamps are supposed to work? |
No clue. @damienmg ? |
@samuraisam what do you mean? If I'm reading your comments correctly, it looks like you are saving If so, I think you might be running into some (likely undocumented) behaviors of how the workspace status/stamping works in Bazel. There's some discussion in bazelbuild/bazel#1758, but basically bazel devices the values into two files, All of the stamping logic (at least The undocumented subtleties apply with custom workspace values. Only values prefixed with |
@samuraisam also, depending how you are defining For example, you can do something like this: docker_push(
name = "push-image",
image = ":image",
registry = "gcr.io",
repository = "$(PROJECT)/my-image",
tag = "dev",
) and then set the project at run-time by doing (You can also combine "make" variables and stamps. e.g. maybe |
@ixdy I actually think the Bazel folks didn't open source the vardef/varref stuff for some strange reason, so we can only use the make variables internally. Have you seen otherwise? |
I tested the example I pasted and it worked. I guess |
... which I think is roughly what you were saying. Someone writing a |
That's interesting, so I guess you can use it, but not with default values? Weird. |
Thanks for the advice. I'm learning more about bazel every day! The primary concern here is that we tag builds with the BUILD_NUMBER eg $PROJECT:$BRANCH_NAME-$BUILD_NUMBER and when $BUILD_NUMBER changes we aren't getting a rebuild. From what I understand this is intended, since bazel produces hermetic builds, we can't change arbitrary values that aren't baked into the environment. To work with this I just run a script afterward that runs |
if you are saving those variables directly into the workspace status, i.e. your #!/bin/sh
echo PROJECT $PROJECT
echo BRANCH_NAME $BRANCH_NAME
echo BUILD_NUMBER $BUILD_NUMBER try prefixing those with #!/bin/sh
echo STABLE_PROJECT $PROJECT
echo STABLE_BRANCH_NAME $BRANCH_NAME
echo STABLE_BUILD_NUMBER $BUILD_NUMBER and then use |
Oh that's awesome! I really appreciate the advice. I do have a workspace_status_command but didn't know about |
In my docker/BUILD file I have something like this to create docker images. Currently this requires
bazel clean
between builds for these services because I haven't figured out how to get the stamps to update every run (which is besides the point, there must be a way).My desire is to define matching docker_push targets:
However this doesn't appear to be supported. I assume there is a reason why that is escaping me. Or maybe I should just be doing this in an external tool.
The text was updated successfully, but these errors were encountered: