oc v3.6.173.0.96
kubernetes v.16.1+5115d708d7
features: Basic-Auth
Problem to solve:
Create pipeline, which will create docker image in specific version (including Jenkins build number, eg. 1.0.1-117). Then it will deploy it to integration environment and then push docker image to external registry (as version 1.0.1-117).
How to pass current version (eg. 1.0.1-117) to my buildconfig:
(...)
spec:
output:
to:
name: external-registry/aaa/my-project:$VERSION
(...)
strategy:
dockerStrategy:
from:
kind: ImageStreamTag
name: 'my-project:$VERSION'
(...)
I checked the help for 'oc start-build' and there are:
The ImageStreamTag "my-project:$VERSION' is invalid: from: Error resolving ImageStreamTag my-project:$VERSION' in namespace aaaa: unable to find latest tagged image
Please advise how to update buildconfig on the fly.
@openshift/sig-developer-experience
Yep, there is no variable substitution performed by the build controller leveraging the env vars for the value in build.Spec.Strategy.DockerStrategy.From.Name.
Using existing capabilities, your pipeline could create a new build config, which you do via oc new-build.., and leverage the --source-image option to point what your are trying to leverage with 'my-project:$VERSION'
Depending on frequencies or needing to change the $VERSION, you'd have to deal with BC sprawl.
Or you could create a custom builder image that manages this.
There is also a trello card and several RFEs in this space ... see https://trello.com/c/nOX8FTRq/686-5-support-multiple-tags-for-a-build-output-builds for details, including elaboration on some of the workarounds.
There is one other possibility. If you're doing a Docker strategy build, you can do this:
make your "FROM" be a docker build arg value:
ARG image
FROM $image
then invoke "oc start-build yourbuild --build-arg image=whateverimage"
Docker will substitute "whateverimage" into $image, achieving the result you want.
you can't use imagestreams this way, and you can't use this w/ s2i, but perhaps it's sufficient for your use case.
@gabemontero https://trello.com/c/nOX8FTRq/686-5-support-multiple-tags-for-a-build-output-builds is about output, not inputs, so i don't know that it's sufficient here (though it is sort of related).
Given that we support "--commit" to run a build for a specific commit, it doesn't seem crazy to me that we'd support "--from-image" to allow specifying the base image to use, but i wouldn't expect it to be a high priority RFE for us.
re: https://trello.com/c/nOX8FTRq/686-5-support-multiple-tags-for-a-build-output-builds yeah I took some creative license in that the solutions I saw could conceivable by applied to inputs, but clarification noted
Thanks you all for responses.
Eventually we decided to use oc patch to update build config with the new released version.
Maybe it is not the perfect solution but solve our problem.
Hi rakk, we are also in the similar situation, can you please provide your build config and oc path command for reference?
Thanks you all for responses.
Eventually we decided to use
oc patchto update build config with the new released version.
Maybe it is not the perfect solution but solve our problem.
Hi rakk, we are also in the similar situation, can you please provide your build config and oc path command for reference?
Sorry for late response.
In Jenkins pipeline:
openshift.withCluster() {
openshift.withCredentials() {
openshift.withProject() {
openshift.patch("bc/your-build-config",
"{ \"spec\": { \"output\": { \"to\": { \"name\": "your-registry.com/your-namespace/your-image:your-version"}}}}"
);
openshift.patch("bc/your-build-config",
"{ \"spec\": { \"strategy\": { \"dockerStrategy\": { \"from\": { \"name\": "your-image:your-version" }}}}}"
);
}
}
}
Or the same with:
sh "oc patch ..."
@bparees
There is one other possibility. If you're doing a Docker strategy build, you can do this:
make your "FROM" be a docker build arg value:
ARG image FROM $imagethen invoke "oc start-build yourbuild --build-arg image=whateverimage"
Docker will substitute "whateverimage" into $image, achieving the result you want.
This does not seem to work on our openshift 3.11 deployment, I have
$ cat Dockerfile.production
ARG CITOOL_IMAGE
FROM $CITOOL_IMAGE
---- snip ----
And I get
$ oc start-build --build-arg CITOOL_IMAGE=docker-registry.some.address.com/baseos-ci/baseosci-citool-bundle-full-devel-fedora29:latest baseosci-openshift-slaves-staging
$ oc logs -f bc/baseosci-openshift-slaves-staging
Cloning "https://gitlab.internal/baseos-qe/ansible-baseos-ci.git" ...
Commit: 70422c43c4666bf29bd46ba67efce85592e9be78 (Use only one Dockerfile, hopefully it will finally work)
Author: Miroslav Vadkerti <[email protected]>
Date: Fri Aug 16 10:29:23 2019 +0200
Pulling image $CITOOL_IMAGE ...
error: build error: failed to pull image: invalid reference format
@thrix can you file a bug at bugzilla.redhat.com? I would expect that to have worked.
@coreydaley i believe you implemented docker build-arg support, so fyi, incoming.
Did the issue above ever get created? Assuming it hasn't been fixed yet, is there a workaround for Dockerfiles with multiple FROM lines?
Did the issue above ever get created? Assuming it hasn't been fixed yet, is there a workaround for Dockerfiles with multiple FROM lines?
If your scenario is that you want to use an ARG to define the image in a FROM command, there is an open PR to address it: https://github.com/openshift/imagebuilder/pull/151
but it will likely not be backported to 3.x
So the only option in 3.x is the hard code the FROM lines?
@dmhursh bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=1801875
@dmhursh you can have openshift do the image substitution for you using As in the buildconfig:
https://github.com/openshift/origin/blob/release-3.11/pkg/build/apis/build/types.go#L629-L635
which will do replacements of FROM references in your dockerfile.
That may or may not be something that's useful in your scenario. Basically it causes a search and replace where we look for the string you put in "As" and replace it with whatever the From field defines/resolves to (https://github.com/openshift/origin/blob/release-3.11/pkg/build/apis/build/types.go#L627)
I'll see if I can make that work. Thanks
Most helpful comment
Sorry for late response.
In Jenkins pipeline:
Or the same with: