WIP: Allow rdgo logic to run local or in CI

[ashcrow]

First pass. Needs work but I'd like to get at least @jlebon to take a gander and see where I'm mucking up in the Jenkinsfile :-).

The make target works. How it's wired in Jenkinsfile has not been tested.

[miabbott]

Feels like we should ultimately be modifying the coreos-assembler container to have these packages installed.

[ashcrow]

@cgwalters WDYT? ⬆️

[cgwalters]

Yeah that's fine by me for now. Down the line we may want multiple containers though.

[miabbott]

https://github.com/cgwalters/coreos-assembler/pull/6

[miabbott]

s/docker/podman ? Ah, nevermind...this is going to be used by Jenkins too, so it is probably not podman aware

[ashcrow]

@miabbott for now that's correct.

[ashcrow]

@miabbott thanks for jumping on this and doing an initial review!

[cgwalters]

Hmm, I don't think this is going to work - Jenkins does a lot of magic in talking to the docker socket to e.g. pass through $WORKSPACE as a hidden volume mount, etc.

[ashcrow]

@cgwalters we're defining $WORKSPACE ourselves via invocation in this PR. Are you saying that the $WORKSPACE variable will end up being overwritten by Jenkins?

[jlebon]

Hmm, I was imagining the Makefile + Jenkinsfile combination to be less high-level. E.g. instead of wrapping the pipeline, it wraps steps inside some stages that'd make life easier (but assumes that all dependencies are already installed). This way it can be run inside the coreos-assembler container in CI as well as locally in pre-existing pet containers. For rdgo, we could have a make rdgo-build (or make rpms?) that just runs some idempotent setup goop + runs rdgo fetch && build. WDYT?

[jlebon]

Are you saying that the $WORKSPACE variable will end up being overwritten by Jenkins?

It's not just the pwd. Environment variables, credentials, etc... Here's a sample from one of our builds where it invokes docker:

$ docker run -t -d -u 0:0 --net=host -v /srv:/srv --privileged -w /var/lib/jenkins/workspace/coreos-rhcos-cloud -v /var/lib/jenkins/workspace/coreos-rhcos-cloud:/var/lib/jenkins/workspace/coreos-rhcos-cloud:rw,z -v /var/lib/jenkins/workspace/coreos-rhcos-cloud@tmp:/var/lib/jenkins/workspace/coreos-rhcos-cloud@tmp:rw,z -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** quay.io/cgwalters/coreos-assembler cat

[ashcrow]

@jlebon yeah we can go lower level. I was hoping we wouldn't have to do so and would be able to have a clean separation between build and delivery. Do you see CI owning the container run and enter or should that be done by the build (IE: make)?

[jlebon]

Hmm, thinking more on this, I'm not sure if this is the best approach to making the local dev case easier. If I look at the steps in #107 for example, those are still simpler than what the pipeline needs to do. E.g. now the cloud pipeline generates 4 cloud image variants using pipeline's parallel feature, which is cool. In local dev though, you probably just want a qcow2 you can boot locally. WDYT about just wrapping the steps in #107? So then folks can just do e.g.:

$ make rdgo
$ make treecompose
$ make qcow2

If this is about replicating the full Jenkins pipeline locally to hack on it; yeah, we definitely something for that. Though probably the easiest way to fix it would be to migrate to OpenShift and use a Jenkins template like we have in PACI: https://github.com/projectatomic/paci/tree/master/jenkins ?

Sorry for the flip on this! This is something I was interested in as well, though I'm unsure right now of the complexity of trying to unify the pipeline with local development.

[ashcrow]

Hmm, thinking more on this, I'm not sure if this is the best approach to making the local dev case easier. If I look at the steps in #107 for example, those are still simpler than what the pipeline needs to do. E.g. now the cloud pipeline generates 4 cloud image variants using pipeline's parallel feature, which is cool. In local dev though, you probably just want a qcow2 you can boot locally. WDYT about just wrapping the steps in #107? So then folks can just do e.g.:

$ make rdgo
$ make treecompose
$ make qcow2

I'm cool with that. The negative here is that if changes in the pipeline for rgdo, treecomposing, or creating images occur they should be reflected in the make file as well ... but I think we can live with that for the time being.

If this is about replicating the full Jenkins pipeline locally to hack on it; yeah, we definitely something for that. Though probably the easiest way to fix it would be to migrate to OpenShift and use a Jenkins template like we have in PACI: https://github.com/projectatomic/paci/tree/master/jenkins ?

I wasn't totally going in for replacing the pipeline in make but in trying to do something that allowed reuse for Jenkins and local devs I think it would have started to fall in to that.

Sorry for the flip on this! This is something I was interested in as well, though I'm unsure right now of the complexity of trying to unify the pipeline with local development.

It's OK! This is how we find out what works and what doesn't :-)

[ashcrow]

What I'll do then is take what's in #107 and turn that into make commands in a new PR.