Cleaning the build docs

[soltysh]

I'll wait for #490 to rebase on top of it. I'll be doing 2nd pass through dev_guide/builds.adoc on Mon.

@bparees @adellape fyi and have a good weekend!

[bparees]

s/a//

[bparees]

@soltysh comments complete.

[soltysh]

@bparees updated comments. I've also noticed we're missing at least some info about custom builder images, so I've added that one to creating-images dir along with sti requirements.
@bparees @adellape @bfallonf ptal, I think I'm done with this 😉

[adellape]

Copy/paste leftover?

[soltysh]

Of course...

[soltysh]

@adellape addressed your comments, except for one, reasoning inline.

[adellape]

@soltysh Sorry, got distracted and wasn't done. :( At least one more comment incoming.

[adellape]

Removing this ==== broke the rest of the headings/TOC.

[adellape]

@soltysh Done commenting, thanks!

[soltysh]

@adellape I'm done

[adellape]

@soltysh LGTM, thanks!

I'll merge when the build passes, unless @bparees wants to add anything.

[bparees]

this isn't really how i'd describe custom builder... the role it fills is basically anything we may not have anticipated in our STI and Docker builders. In addition the most likely use case is not to produce a new docker image (use Docker or STI builds for that), it's to produce individual artifacts like jars, wars, installable zips, etc. The point is that it can perform any steps you want to produce some output artfact, and then is responsible for pushing that artifact to some location (eg scp'ing it to a server).

It also provides a backdoor way of introducing a CI/CD flow since you could write a custom builder that runs unit or integration tests, in theory. (sort of like the Jenkins custom job type)

[soltysh]

I'll update this in a follow up PR.
On Jun 15, 2015 6:58 PM, "Ben Parees" notifications@github.com wrote:

In creating_images/custom.adoc
#492 (comment)
:

+{product-author}
+{product-version}
+:data-uri:
+:icons:
+:experimental:
+:toc: macro
+:toc-title:
+
+toc::[]
+
+== Overview
+link:../architecture/core_objects/builds.html#custom-build[Custom build] is designed
+to fill the gap that was created when everybody jumped into creating docker images.
+Still there is a requirement to produce packages with all the software being installed
+and most importantly one needs to be able to build base docker images. This is
+where Custom build is the perfect match to fill in that gap.

this isn't really how i'd describe custom builder... the role it fills is
basically anything we may not have anticipated in our STI and Docker
builders. In addition the most likely use case is not to produce a new
docker image (use Docker or STI builds for that), it's to produce
individual artifacts like jars, wars, installable zips, etc. The point is
that it can perform any steps you want to produce some output artfact, and
then is responsible for pushing that artifact to some location (eg scp'ing
it to a server).

It also provides a backdoor way of introducing a CI/CD flow since you
could write a custom builder that runs unit or integration tests, in
theory. (sort of like the Jenkins custom job type)

—
Reply to this email directly or view it on GitHub
https://github.com/openshift/openshift-docs/pull/492/files#r32441856.

[bparees]

👍