-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[OPENJDK-2735] Phase-3 BuildConfig template for multistage build for jlinked image #461
Conversation
This is looking good! I'll leave some comments. |
dockerfile: | | ||
#Stage-1: ubi9-jlinked-image is builder image + application + jlinked JVM | ||
# install additional system dependencies (for ubi-micro) to /mnt/jrootfs | ||
FROM ubi9-jlinked-image AS ubi9-jlinked-image # Replace this with appropriate base image |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We wil want OpenShift to substitute FROM ubi9-jlinked-image
with the correct imagestream name/URI for the specific instance of this template once deployed. To achieve that, change this line to FROM - AS ubi9-jlinked-image
; and then we also need to add some more metadata elsewhere in the buildConfig, a dockerStrategy
key underneath strategy:
, which will describe the ImageStream to pull from. See https://docs.openshift.com/container-platform/4.15/cicd/builds/build-strategies.html#builds-strategy-docker-from-image_build-strategies
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aha, quoting that URI, we may have a problem: "If the Dockerfile uses multi-stage builds, the image in the last FROM instruction will be replaced.", so in this case, that would be the ubi-micro below, not what we want.
We might have to switch from a mutistage dockerfile to two separate, linked OpenShift buildConfigs instead.
I don't think switching to Two approaches that might work are moving the first stage work into Phase 1, or wrapping the whole thing up in an OpenShift template, and using the template parameters to substitute the FROM. We are going to be using OpenShift templates for other aspects, so it would be worth looking at that now. |
spec: | ||
source: | ||
dockerfile: | | ||
#Stage-1: ubi9-jlinked-image is builder image + application + jlinked JVM |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
error parsing multistage-buildconfig.yaml: error converting YAML to JSON: yaml: line 8: found a tab character where an indentation space is expected
metadata: | ||
generation: 1 | ||
name: jlinked-image | ||
namespace: default |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove this line
dockerfile: | | ||
#Stage-1: ubi9-jlinked-image is builder image + application + jlinked JVM | ||
# install additional system dependencies (for ubi-micro) to /mnt/jrootfs | ||
FROM - AS ubi9-jlinked-image # Replace this with appropriate base image |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since we cannot rely on OpeNShift to substitute "-" here, for dev purposes we could use FROM quay.io/jdowland/jlink:ubi9-jlinked-image as ubi9-jlinked-image
… for jlinked image Signed-off-by: Jayashree Huttanagoudar <[email protected]>
… a new file multistage-buildconfig1.yaml with another strategy Signed-off-by: Jayashree Huttanagoudar <[email protected]>
Signed-off-by: Jayashree Huttanagoudar <[email protected]>
ddaa113
to
78a7ac8
Compare
…stage-1 and stage-2 in the multistage Dockerfile. Also use proper BuildConfig objects to replace FROM, ENV and ARG in the Dockerfile. Signed-off-by: Jayashree Huttanagoudar <[email protected]>
On my local crc setup I tried to create the template as follows:
Further I tried to process the template and end-up with some errors :)
Looks like some wrong stuff is fed for build strategy !. |
These are just indentation errors I think: It's saying the buildconfigs don't have |
dockerStrategy: | ||
from: | ||
kind: ImageStreamTag | ||
name: quay.io/repository/jdowland/jlink:ubi9-jlinked-image |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a registry URI , but it needs to be an ImageStreamTag. The eventually-correct value for this will depend upon Josh's Phase 2 template. for now you could put jlinked-image
which definitely exists (your template creates it) as a placeholder. I'd put a comment after # placeholder value
dockerfile: | | ||
#Stage-1: ubi9-jlinked-image is builder image + application + jlinked JVM | ||
# install additional system dependencies (for ubi-micro) to /mnt/jrootfs | ||
FROM - |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
until the dockerStategy.from.name
below is the valid image stream, I'd put the test image URI here: FROM quay.io/repository/jdowland/jlink:ubi9-jlinked-image
imageChange: | ||
from: | ||
kind: ImageStreamTag | ||
name: quay.io/repository/jdowland/jlink:ubi9-jlinked-image # ImageStreamTag to trigger the build (stage-1 in Dockerfile) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
likewise this is not a valid ImageStreamTag. Put a placeholder value in until we know a real one further along development
dockerStrategy: | ||
from: | ||
kind: ImageStreamTag | ||
name: registry.access.redhat.com/ubi9/ubi-micro |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not a valid ImageStream tag. use a placeholder
source: | ||
dockerfile: | | ||
#Stage-2:copy application JAR and jlinked JRE to runtime image | ||
FROM - |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this doesn't need to be parameterized I don't think. use FROM registry.access.redhat.com/ubi9/ubi-micro
. (I wonder if we should actually define an ImageStream for ubi-micro or not.)
#Stage-2:copy application JAR and jlinked JRE to runtime image | ||
FROM - | ||
|
||
COPY --from=ubi9-jlinked-image /mnt/jrootfs/ / |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these instructions will only work in a Dockerfile multi-stage build, since there's nothing labelled "ubi9-jlinked-image" in these instructions now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we replace FROM instruction with quay image directly as FROM quay.io/repository/jdowland/jlink:ubi9-jlinked-image
then the output.to.name
is ubi9-jlinked-image
. My understanding is that this is made available by the first buildConfig that is ubi9-jlinked-image-buildconfig
Correct me if I am wrong
imageChange: | ||
from: | ||
kind: ImageStreamTag | ||
name: registry.access.redhat.com/ubi9/ubi-micro # ImageStreamTag for the final output image (stage-2 in Dockerfile) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this isn't a valid ImageStreamTag. If we wan't to trigger a rebuild when ubi-micro is changed, we will need to define a ubi-micro ImageStream. Perhaps we should
--setopt=varsdir=/etc/dnf/vars \ | ||
grep gawk | ||
RUN rm -rf /mnt/jrootfs/var/cache/* /mnt/jrootfs/var/lib/rpm /mnt/jrootfs/var/lib/dnf | ||
strategy: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this key belongs under spec
not spec.source
|
||
USER 185 | ||
CMD /opt/jboss/container/java/run/run-java.sh | ||
strategy: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this key belongs under spec
not spec.source
This is looking great. I'm not 100% sure that we should split the build into two |
Signed-off-by: Jayashree Huttanagoudar <[email protected]>
Thanks for the review. |
Signed-off-by: Jayashree Huttanagoudar <[email protected]>
With the recent commit able to create two separate BuildConfigs for stage-1 and stage-2 in our multi-stage Dockerfile
|
Some notes on the current status: The first buildConfig cannot be run because of a dependency issue
The ImageStream exists, but there is no :latest tag, because no builds have run yet. The buildConfig outputs to that ImageStream, so we cannot also depend upon it. Removing Next problem, builds from that build Config still fail, " Output image could not be resolved.". The output is described as The builds fail because The next problem is, after the build succeeds, it updates the |
On to the second buildConfig, This second buildConfig is defined to build from, and also write to, builds from the second buildConfig fail at the |
Signed-off-by: Jayashree Huttanagoudar <[email protected]>
With the recent changes
But the
|
…to resolve the second BuildConfig indefinite pending status Signed-off-by: Jayashree Huttanagoudar <[email protected]>
I am not sure whether custom build strategy is useful to handle COPY instructions in the |
Closing this PR as we are focusing on #471 |
This is still WIP and an initial attempt to write a BuildConfig template.