Skip to content
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

S2I Chained builds #1216

Open
tommaso-borgato opened this issue Feb 20, 2023 · 11 comments
Open

S2I Chained builds #1216

tommaso-borgato opened this issue Feb 20, 2023 · 11 comments
Labels
triage/support Indicates an issue that is a support question.

Comments

@tommaso-borgato
Copy link

tommaso-borgato commented Feb 20, 2023

Enhancing the s2i build strategy, e.g. with a new parameter, in order to manage s2i chained builds;

This enhancement would allow us to handle WildFly s2i builds (see https://github.com/wildfly/wildfly-s2i/) which use a builder and a runtime image; in WildFly s2i builds two images are defined, one for the actual build and one for the runtime:

  s2i:
    builderImage: wildfly-s2i:latest-jdk17
    runtimeImage: wildfly-runtime:latest-jdk17
@SaschaSchwarze0
Copy link
Member

SaschaSchwarze0 commented Feb 20, 2023

@SaschaSchwarze0
Copy link
Member

@tommaso-borgato thanks for the issue.

We were just looking at that project and at this example, https://github.com/wildfly/wildfly-s2i/tree/main/examples/docker-build. But, we don't get the full picture.

Do you have a full e2e example by chance which includes the source code repository, and the commands that one must run that produce the container image. Then we can better assess if and how this is doable with Shipwright Build ?

@SaschaSchwarze0 SaschaSchwarze0 added the triage/support Indicates an issue that is a support question. label Feb 20, 2023
@tommaso-borgato
Copy link
Author

tommaso-borgato commented Feb 21, 2023

You can do it with HELM (https://github.com/wildfly/wildfly-charts) and this is actually the scenario we would like to cover:

oc new-project shipwright

helm repo add wildfly https://docs.wildfly.org/wildfly-charts/

cat > values.yaml << EOF
build:
  uri: https://github.com/wildfly/quickstart.git
  ref: main
  contextDir: helloworld
deploy:
  replicas: 1
EOF

helm install my-release -f ./values.yaml wildfly/wildfly --namespace shipwright

You'll notice two builds will be started (my-release-build-artifacts-1-build --> my-release-2-build):

image

  • my-release-build-artifacts-1-build: actually performs the maven build and produces a trimmed WildFly server + WAR
  • my-release-2-build: copies trimmed WildFly server + WAR to the runtime image

@tommaso-borgato
Copy link
Author

@SaschaSchwarze0 ^^^

@SaschaSchwarze0
Copy link
Member

Thanks for the details @tommaso-borgato. So basically a build strategy would need to contain two steps:

  1. A build step.
  2. An image build (and push) step.

What I wonder is how generic that is. It would be no issue to set this up, like step (1) using a Java+Maven image and running a Maven build. And then a second step which uses maybe crane append to add a layer with the output of step (1) to a runtime image. That would be no magic, but very specific to your source code that must be Java+Maven and produce a WAR file.

Assuming it is simple, then so far, our sample build strategies are more generic (maybe with the exception of ko which is specific for Go code). Does not mean that one should not build this, I am also having local build strategies that do similar things in the NodeJS world. And it maybe makes sense to have one or two samples that show this pattern.

What could also be the case as you mention builder image: one could build a generic build strategy where the image of step (1) is a parameter. For your Java app, you use image a, for my node app, I use image b. When those images run, they will run the build and put the output somewhere. And then step (2) would take that output and append it to the parameterized run image as a layer, and somehow define the image's entrypoint.

@tommaso-borgato
Copy link
Author

tommaso-borgato commented Feb 21, 2023

@SaschaSchwarze0 the process is described here https://github.com/openshift/source-to-image/blob/master/docs/runtime_image.md

I suppose that, if s2i cli is used internally, we just need to pass two more parameters --runtime-image <runtime-image> --runtime-artifact </path/to/artifact>, e.g.:

s2i build <repo> <builder-image> <my-app> --runtime-image <runtime-image> --runtime-artifact </path/to/artifact>

@SaschaSchwarze0
Copy link
Member

Okay, so, are you then just asking for the addition of --runtime-image into https://github.com/shipwright-io/build/blob/main/samples/buildstrategy/source-to-image/buildstrategy_source-to-image_cr.yaml ?

@tommaso-borgato
Copy link
Author

and --runtime-artifact

@SaschaSchwarze0
Copy link
Member

Okay, do you have a full example for me then. And sorry to ask so stupid questions, but I never used s2i.

s2i build <WHICH SOURCE CODE, the wildfly hello world?> <WHICH_BUILDER> --runtime-image <WHICH_RUNTIME> --runtime-artifact <WHICH_ARTIFACT>

And is --runtime-artifact a single value or can this appear more than once ?

@tommaso-borgato
Copy link
Author

give me some time to put one together ....

@tommaso-borgato
Copy link
Author

tommaso-borgato commented Mar 10, 2023

e.g.

s2i build https://github.com/tommaso-borgato/helloworld.git quay.io/wildfly/wildfly-s2i-jdk11 my-release --ref=main --runtime-image=quay.io/wildfly/wildfly-runtime-jdk11 --runtime-artifact=/opt/server --assemble-user=root --assemble-runtime-user=root 

the resulting image doesn't start correctly yet (need to fix something) but the chained s2i build is successful

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage/support Indicates an issue that is a support question.
Projects
None yet
Development

No branches or pull requests

2 participants