Closed deads2k closed 8 years ago
the imageid is only known by the build pod. build.status doesn't contain any information like that. the build pod would have to call back to the api to update the status with such information (this is the same reason it doesn't currently contain the exact commit id that got cloned/built, for example).
that said, oc build-logs should be showing you the image that was pushed, no?
Given that the build pod will run with a known service account, should we simply give that service account rights to update the field?
i feel like this has been discussed elsewhere...do we have that level of granularity available?
i feel like this has been discussed elsewhere...do we have that level of granularity available?
We could grant rights to update builds. It doesn't seem unreasonable for a build controller identity to have those permissions.
could we update build/status instead, to avoid interference from admission checks intended to guard docker/source/custom build types?
related discussion: https://trello.com/c/3GzMxKzg/656-ability-to-truly-rerun-a-build
There was another issue for this.
related (probably the issue @smarterclayton is referring to?): https://github.com/openshift/origin/issues/615
There's also something similar but regarding push spec in #2982
This was requested again recently
since we now update the build status with the commit id we built, we are probably have most of the pieces in place that we'd need to do this for the imageid that resulted from the build as well.
trello'd https://trello.com/c/SAvLJLLl
I'm trying to do a
kubectl run
using the image built two builds ago. I know which build I'm interested in, but I can't easily go from there to knowing the image URL.Build.Status
already contains fields that could only have been known after the build finished. Can we the exactly image?@bparees