On 10 January 2017 at 15:35, Roman Mohr <rm...@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 bkor...@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel