Enhancing std-ci for deployment (std-cd)

[Barak Korren]

Hi all,

I'm contemplating the best way to enable including deployment logic in
standard-CI scripts.

Case to the point - embedding the deployment logic of our infra-puppet
repo. One thing to note about this, is that deployment in this
scenario can happen either post-merge (Like it does today) or
pre-merge (Create a per-patch puppet env to enable easy testing)

I can think of a few ways to go about this:

1. Copy the full generated puppet configuration into
'exported-artifacts' and add logic to the YAML to copy it to the
foreman server.

The main shortcoming of this is that we will have to maintain quite a
bit of custom logic in the YAML. This beats the purpose of embedding
the logic in the source repo in the 1st place.

2. Mount the '/etc/puppet' directory into the chrrot

This will require having the foreman be a Jenkins slave and some
custom YAML to ensure the jobs run on it (not a big deal IMO)

The shortcoming is that running tests locally with mock_runner would
be cumbersome (It will touch your local /etc/puppet directory and
probably fail). Another issue is that we will have to find a way to
figure out Gerrit patch information from inside mock. Possibly we
could use the commit message or git hash for that.

3. Invent some kind of a new deploy_*.sh script

This makes it possible to run the checking code locally without the
deployment code. The YAML changes for this could be quite generic and
shared with other projects. We could possibly also invent a
'deploy_*.target' to specify where to run the deploy script (E.g. a
Jenkins label).

We could even consider not running the script inside mock, though I
think mock's benefits outweigh the limits it imposes on accessing the
outside system (which can be mostly bypassed anyway with bind mounts).

So,
WDYT?

-- 
Barak Korren
bkorren at redhat.com
RHEV-CI Team