One step builds.

[jayunit100]

This is a starter issue to collect feedback on what the README needs to make it a one step build.

cc @mattfenwick @msenmurugan leave comments and feedback in here, we will craft a PR accordingly. possibly consider:

• docker-in-docker one step builder
• Vagrantfile one step builder
• makefile bootstrap itself a little better
• simply have the truly 'from zero' instructions in the README
• others?

[xenserverarmy]

I think the first order of business is to define "build". I build all the time, and my current single line is: make tar-build -e BDS_VER=4.3.0. Seems pretty much a "one step" to me, so clearly I'm missing something.

We could add that to the wiki, and I'd argue the wiki is way out of date so perhaps this issue is more of a "update the wiki with more up to date build/compile instructions"?

[jayunit100]

http://2013.drupalcamp.at/session/love-thy-vagrant First paragraph is what we want here.

[mattfenwick]

Just for a bit of context, this is all from the perspective of somebody totally new to this project and to BlackDuck, and my original goal was just to get things building and running so that I could add a simple unit test ...

• "The build server requires Golang and Docker and will require a Hub scan engine from a Black Duck Hub instance." I don't know where or how these need to be running, what versions are required, and what configuration needs to be done to make them accessible from ose-scanner.
• Where do I get a Hub scan engine? I'm not sure what that means.
• Do I need OpenShift running on my own machine, or is it supposed to be running somewhere else?
• Where and how does Black Duck Hub need to be running?
• Once everything is up and running, how do I verify that everything's working correctly?
• moving the build steps to the readme will allow them to stay in sync with the code (to avoid the scenario where there are different build steps for different versions, and it's not clear which version the wiki is for)

[mattfenwick]

@jayunit100 just for comparison, I was looking at the kubernetes repo and their process is:

• setup golang
• $ go get -d k8s.io/kubernetes
• $ cd $GOPATH/src/k8s.io/kubernetes
• $ make

[jayunit100]

Im gonna propose the best path would be

• building a vagrant image on virtualbox, which embeds a scan client, and docker , and a go version
• pushing that image to atlas.
• bundling a vagrantfile that uses that image to build the scan client and run all unit tests, into this repository.
• modify the top level README with a 'quick start for local hacking: vagrant up'.

Votes Up or Down or alternate proposals @rrati @robpacheco @xenserverarmy @mattfenwick @msenmurugan ?

[xenserverarmy]

OK, so this isn't about a "one step build", but instead "how do I create a dev environment". Gotcha.

I have no problem with a vagrant box containing centos7, docker and Go. To be honest, you could just take this[1] and run with it doing a yum install docker go

Embedding a scan client I'm not in favor of as that would be to release to Atlas something which isn't normally publically accessible and which will change. Far better to have internal developers understand where to get it (which they're going to need to know anyway), and to provide similar instructions for external developers.

As to the questions @mattfenwick raised around "what's a Hub and how do I get one", those are part of how Black Duck develops so internal developers should already have that knowledge available to them as part of onboarding and external developers should already have a Hub instance provisioned for them.

Last part of the question would be "Where do I run OpenShift", that has many answers but the simplest would be to either provision a RHT CDK (which would also be a vagrant box) or an Origin instance. Of course we'd want to ensure all real testing is done with OCP, but for developers Origin should be sufficient save for the most problematic bugs. I would tend to stay away from minishift as its a bit too divergent for what this project is all about. Do bear in mind that a dev vagrant box + Hub + Origin is likely way more RAM requirements than someone is going to have on their laptop which is why I'd expect Hub + Origin to be in virtual infra someplace.

[1] https://app.vagrantup.com/centos/boxes/7