Platform independent image builds

[ironcladlou]

Make the build/release process more generic to allow multiple release targets
such as core and image binaries. This makes the build/release process once
again platform independent (provided docker is available on the host), and
re-enables support for build-release/build-images on OSX.

[ironcladlou]

@smarterclayton This solves it. It would have been much simpler to just include the binary in the release tar, but this does the job.

[ironcladlou]

[test]

[openshift-bot]

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_openshift3/1093/)

[ironcladlou]

@smarterclayton If you also think this fixes the problem, maybe we could get it merged for beta1 with a refactor followup? I avoided the hello image because it seems to have a binary committed rather than following the bin directory convention, and I didn't want to do too much at once yet.

[smarterclayton]

Not beta1

[ironcladlou]

Alright, but it's unfortunate that what's in master went from working to broken suddenly.

[smarterclayton]

Also build assets

[ironcladlou]

@smarterclayton

Also build assets

Can you elaborate on this? I'm happy to keep running with the PR for beta2.

[smarterclayton]

If the release image was capable of building assets (not by default, but in a mode we can run) it would benefit folks deving on weird systems.

On Feb 5, 2015, at 10:26 AM, Dan Mace notifications@github.com wrote:

@smarterclayton

Also build assets

Can you elaborate on this? I'm happy to keep running with the PR for beta2.

—
Reply to this email directly or view it on GitHub.

[smarterclayton]

We can nuke the committed binary - it was convenient, that's all.

On Feb 4, 2015, at 9:51 PM, Dan Mace notifications@github.com wrote:

@smarterclayton If you also think this fixes the problem, maybe we could get it merged for beta1 with a refactor followup? I avoided the hello image because it seems to have a binary committed rather than following the bin directory convention, and I didn't want to do too much at once yet.

—
Reply to this email directly or view it on GitHub.

[csrwng]

This is working for me on boot2docker:

#!/bin/sh
docker run \
   -v $GOPATH/src/github.com/openshift/origin:/go/src/github.com/openshift/origin \
   -v /usr/local/bin/docker:/usr/bin/docker \
   -v /var/run/docker.sock:/var/run/docker.sock \
   -e OS_VERSION_FILE="" \
   openshift/origin-release hack/build-images.sh

[ironcladlou]

@csrwng One nit with that approach is that you're building bind mounted source through the VM rather than letting the origin-release container build from the source that was prepared and streamed to it.

@smarterclayton I had one more idea to revise what I have here: what if instead of building just 1 release tar and pulling down the image binaries separately place_bins was modified to produce the release tar (excluding image binaries), and a second image binaries tar (including only image binaries)? Then the build-release.sh could:

1. Pull down and verify the release tar
2. Pull down and verify image tar(s)
3. Untar both to the same place

I think that seems more internally consistent than what I have so far.

[smarterclayton]

Yes.

----- Original Message -----

@csrwng One nit with that approach is that you're building bind mounted
source through the VM rather than letting the origin-release container build
from the source that was prepared and streamed to it.

@smarterclayton I had one more idea to revise what I have here: what if
instead of building just 1 release tar and pulling down the image binaries
separately place_bins was modified to produce the release tar (excluding
image binaries), and a second image binaries tar (including only image
binaries)? Then the build-release.sh could:

1. Pull down and verify the release tar
2. Pull down and verify image tar(s)
3. Untar both to the same place

I think that seems more internally consistent than what I have so far.

---

Reply to this email directly or view it on GitHub:
#897 (comment)

[ironcladlou]

@smarterclayton Check out this new revision.

[smarterclayton]

Do hello-Openshift as well

[ironcladlou]

@smarterclayton

Ready for another review. I think I managed to get the release builder just generic enough to support our core/images splits.

[ironcladlou]

@smarterclayton I know you've been busy with an upstream refactor, so I promise to ping you about this only once a day. ☺️

[ironcladlou]

Rebased.

[ironcladlou]

@smarterclayton Psssst.

[smarterclayton]

Have you got a passing jenkins test?

[ironcladlou]

Figures... it was green for days and when you come back around everything's red red red

[ironcladlou]

Rebased again, waiting for results.

[smarterclayton]

LGTM [merge]

[openshift-bot]

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_openshift3/941/) (Image: devenv-fedora_814)

[openshift-bot]

Evaluated for origin up to 794be1e