[Openshift Commons Image Builders SIG] source2image and compiling java...where's the right place to do it?

[Marc Boorshtein]

Thanks Jorge.  I'd think it'd be good to have both option 1 (source)
and option 2 (binaries) since option 1 is good for just testing
locally but if you have a full ci/cd pipeline it would be better for
the ci/cd pipeline to do the build to get the benefits of managing of
having consistent artifacts?

Thanks
Marc Boorshtein
CTO Tremolo Security
marc.boorshtein at tremolosecurity.com
(703) 828-4902
Twitter - @mlbiam / @tremolosecurity


On Thu, Jun 2, 2016 at 3:57 AM, Jorge Morales Pou <jmorales at redhat.com> wrote:
> Hi Marc,
> 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).
> For this, we've been working, and keep doing, into making this scenario
> easier, by:
> - Making a source repository optional (OSE 3.3)
> - Providing binaries to the build process (3.2:
> https://docs.openshift.com/enterprise/3.2/dev_guide/builds.html#binary-source)
> - Providing content from another image (3.2:
> https://docs.openshift.com/enterprise/3.2/dev_guide/builds.html#image-source)
> - Splitting the build process into builder + runtime images (3.3)
> - Provide additional information in webhooks (3.3)
> 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.
> https://docs.openshift.com/enterprise/3.2/dev_guide/builds.html#using-external-artifacts
> http://blog.andyserver.com/2016/03/getting-to-the-cloud-faster-with-binary-builds-on-openshift/
>
> 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 https://github.com/openshift-s2i/s2i-wildfly/tree/master/10.0).
> 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:
> https://trello.com/c/MWUAjl6k/237-13-extended-builds-separate-mvn-vs-jboss-evg.
> 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.
>
> The 3rd option seems like a big boilerplate to craft in an image, so I would
> rather recommend either option 2 or 1.
>
> Hope this helps,
>
> Jorge Morales
> OpenShift by Red Hat
> EMEA Field Product Manager
> Product Marketing Manager
>
> On Wed, Jun 1, 2016 at 6:05 PM, Marc Boorshtein
> <marc.boorshtein at tremolosecurity.com> wrote:
>>
>> Fellow builders,
>>
>> We're building a source2image builder for our Java application and
>> we're struggling with the question of where to actually build the
>> system.  The output of a maven build process is a war file that goes
>> into a hardened version of Tomcat.  We see three options:
>>
>> 1.  Input is a war file created as the output of an external build -
>> simple for us but seems to defeat the purpose of s2i
>>
>> 2.  Assume that maven and javac are wherever s2i is running and have
>> the assemble script pull the maven project, build it and deploy the
>> war file into the image - This seems the most obvious to me since it
>> lets us rely on existing build processes.
>>
>> 3.  Pull in maven and the source code into the image, then have the
>> image build the project, deploy the wars and then remove maven and the
>> source code - This seems like it would be the most consistent way to
>> do a build since it wouldn't matter which system s2i runs on but it
>> requires the most amount of work on our end.
>>
>> Any thoughts/advise on the best or recommended approach?  Is there one
>> that we're missing?
>>
>> Thanks
>>
>>
>> Marc Boorshtein
>> CTO Tremolo Security
>> marc.boorshtein at tremolosecurity.com
>> (703) 828-4902
>> Twitter - @mlbiam / @tremolosecurity
>>
>> _______________________________________________
>> Openshift-commons-sig-image-builders mailing list
>> Openshift-commons-sig-image-builders at redhat.com
>>
>> https://www.redhat.com/mailman/listinfo/openshift-commons-sig-image-builders
>
>