<div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Marc,</div><div class="gmail_default" style="font-size:small">Our current s2i builders expect the source code to be provided, and the build to happen in OpenShift, but this is just an actual limitation of our builders rather than the platform. A custom s2i image can be crafted so that instead of expecting the source code to build the application, it just get's the generated artifact and layers that on top of a runtime image (Tomcat in your example).</div><div class="gmail_default" style="font-size:small">For this, we've been working, and keep doing, into making this scenario easier, by:</div><div class="gmail_default" style="font-size:small">- Making a source repository optional (OSE 3.3)</div><div class="gmail_default" style="font-size:small">- Providing binaries to the build process (3.2: <a href="https://docs.openshift.com/enterprise/3.2/dev_guide/builds.html#binary-source">https://docs.openshift.com/enterprise/3.2/dev_guide/builds.html#binary-source</a>)</div><div class="gmail_default" style="font-size:small">- Providing content from another image (3.2: <a href="https://docs.openshift.com/enterprise/3.2/dev_guide/builds.html#image-source">https://docs.openshift.com/enterprise/3.2/dev_guide/builds.html#image-source</a>)</div><div class="gmail_default" style="font-size:small">- Splitting the build process into builder + runtime images (3.3)</div><div class="gmail_default" style="font-size:small">- Provide additional information in webhooks (3.3)</div><div class="gmail_default" style="font-size:small">With these tools in place, it would be trivial to make an s2i that fetches a binary artifact from an artifact repository manager (nexus, artifactory) on the coordinates provided via webhook or start-build options, and just layer the artifact into a runtime image. This will be an OOTB scenario for 3.3, until then, some manual crafting need to be done, but still possible, by a custom assemble script as an example.</div><div class="gmail_default" style=""><a href="https://docs.openshift.com/enterprise/3.2/dev_guide/builds.html#using-external-artifacts">https://docs.openshift.com/enterprise/3.2/dev_guide/builds.html#using-external-artifacts</a><br></div><div class="gmail_default" style=""><a href="http://blog.andyserver.com/2016/03/getting-to-the-cloud-faster-with-binary-builds-on-openshift/">http://blog.andyserver.com/2016/03/getting-to-the-cloud-faster-with-binary-builds-on-openshift/</a><br></div><div class="gmail_default" style=""><br></div><div class="gmail_default" style="">If your using one of our s2i, option 2 seems the way to go (or even if you're crafting your own, you can follow similar approach, following our wildfly s2i <a href="https://github.com/openshift-s2i/s2i-wildfly/tree/master/10.0">https://github.com/openshift-s2i/s2i-wildfly/tree/master/10.0</a>). As I mentioned before, we will be splitting builder and runtime image, so you will no longer need to have javac + maven on the s2i image, but rather you'll have a maven builder and a tomcat runtime, and the generated artifact will be copied from the former to the later automagically in the s2i process. You can see details here: <a href="https://trello.com/c/MWUAjl6k/237-13-extended-builds-separate-mvn-vs-jboss-evg">https://trello.com/c/MWUAjl6k/237-13-extended-builds-separate-mvn-vs-jboss-evg</a>. This is a Work in Progress, that will be in OSE 3.3. Also, this can be currently achieved by combining 2 builds and chaining them. The image built in the first build (which would be just java + maven) will be used as source for the second build to get the artifact into a plain Tomcat. </div><div class="gmail_default" style=""><br></div><div class="gmail_default" style="">The 3rd option seems like a big boilerplate to craft in an image, so I would rather recommend either option 2 or 1.</div><div class="gmail_default" style=""><br></div><div class="gmail_default" style="">Hope this helps,</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Jorge Morales<div>OpenShift by Red Hat</div><div>EMEA Field Product Manager</div><div>Product Marketing Manager</div></div></div></div>
<br><div class="gmail_quote">On Wed, Jun 1, 2016 at 6:05 PM, Marc Boorshtein <span dir="ltr"><<a href="mailto:marc.boorshtein@tremolosecurity.com" target="_blank">marc.boorshtein@tremolosecurity.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Fellow builders,<br>
<br>
We're building a source2image builder for our Java application and<br>
we're struggling with the question of where to actually build the<br>
system. The output of a maven build process is a war file that goes<br>
into a hardened version of Tomcat. We see three options:<br>
<br>
1. Input is a war file created as the output of an external build -<br>
simple for us but seems to defeat the purpose of s2i<br>
<br>
2. Assume that maven and javac are wherever s2i is running and have<br>
the assemble script pull the maven project, build it and deploy the<br>
war file into the image - This seems the most obvious to me since it<br>
lets us rely on existing build processes.<br>
<br>
3. Pull in maven and the source code into the image, then have the<br>
image build the project, deploy the wars and then remove maven and the<br>
source code - This seems like it would be the most consistent way to<br>
do a build since it wouldn't matter which system s2i runs on but it<br>
requires the most amount of work on our end.<br>
<br>
Any thoughts/advise on the best or recommended approach? Is there one<br>
that we're missing?<br>
<br>
Thanks<br>
<br>
<br>
Marc Boorshtein<br>
CTO Tremolo Security<br>
<a href="mailto:marc.boorshtein@tremolosecurity.com">marc.boorshtein@tremolosecurity.com</a><br>
<a href="tel:%28703%29%20828-4902" value="+17038284902">(703) 828-4902</a><br>
Twitter - @mlbiam / @tremolosecurity<br>
<br>
_______________________________________________<br>
Openshift-commons-sig-image-builders mailing list<br>
<a href="mailto:Openshift-commons-sig-image-builders@redhat.com">Openshift-commons-sig-image-builders@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/openshift-commons-sig-image-builders" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/openshift-commons-sig-image-builders</a><br>
</blockquote></div><br></div>