[ovirt-devel] Toward self-configuring CI, or how can we stop writing YAML

[Barak Korren]

On 10 January 2017 at 15:35, Roman Mohr <rmohr at redhat.com> wrote:
>
>> > different yaml files, but as Martin says the rest is there. What they
>> > have
>> > is different steps inside one yaml file (setup, pre_script, post_script,
>> > deployment, ...)
>> > which can be triggered according to branches and tags.

In standard CI, we try to walk a fine line between keeping everything
as simple as possible to do (put the script there), and enabling
complex behaviour (you can have a specific script for a specific arch,
and we're gonna run the whole OST flow once you merge).

The easiest thing for us would be to just tell everyone to put a
'Jenkinsfile' in their repo and be done with...

>> > In Kubevirt we also use a .travis.yaml which does testing and releasing
>> > based on tags and branches [1].
>> >
>> > Note that for more finetuned controls, they also provide a lot of
>> > environment variables which you can reference (e.g. branch, tag, ...)
>>
>> Lets not run this into an off-topic 'travis vs. foo' discussion. This
>> is not going anywhere.
>
> Not trying to make any point, except from providing insight how travis is
> doing it. Since it might be useful.

Ok, then let me try to say something about the environment variables.
One of the design goals of the standard-CI had always been to also
enable local reproduction of the CI flow (In case you didn't know, you
can use 'muck_runner.sh' to run the CI scripts in almost exactly the
same way Jenkins does it). This is why we tend to not provide any more
contextual information then you would have while running the script on
your laptop.

Having said that, its quite easy for us to provide every last bit of
information Gerrit has about a given patch. Make concrete requests and
we will accommodate.

-- 
Barak Korren
bkorren at redhat.com
RHCE, RHCi, RHV-DevOps Team
https://ifireball.wordpress.com/