On 5 February 2017 at 19:25, Nir Soffer <nsof...@redhat.com> wrote: > On Sun, Feb 5, 2017 at 11:33 AM, Martin Sivak <msi...@redhat.com> wrote: >>> A repo where I do not have commit rights means I can't take full >>> responsibility. > > May pain points with jenkins project: > > - No documentation
Please: http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Build_and_test_standards.html > - The format is not stable, each time you edit the format is different Nope. The examples in the doc above haven't change much, you can just do more. > - No way to test changes, only infra guys can test changes, sometimes > even infra guys cannot test changes and they simply merge them > for testing Just submit a patch the the Jenkins repo - it gets tested and you get detailed report. For example: http://jenkins.ovirt.org/job/jenkins_master_check-patch-el7-x86_64/797/artifact/exported-artifacts/differences.html > - The project format is full of duplication Some files are unnecessarily messy, but there is no real duplication in the format itself. > - No commit right, cannot be responsible for something I cannot change Nobody asked you to be responsible for the whole repo. Just a few files in it that contain information the integration/infra teams cannot possibly know. > > Compare with travis: > > - Everting defined in *my* project in .travis.yml See thread I mentioned above. > - Configuration format is well documented > https://docs.travis-ci.com/ We got docs too. > - Configuration format is well designed, can do lot of work with very > little configuration > For example - this yaml define matrix of 3 builds: > https://github.com/oVirt/vdsm/blob/master/.travis.yml And this will make a 12 job matrix: project: name: 'vdsm_standard' project: vdsm trigger: 'on-change' version: - master: branch: master - 4.1: branch: ovirt-4.1 - 4.0: branch: ovirt-4.0 - 3.6: branch: ovirt-3.6 distro: - el7 - fc24 - fc25 Not really that different. The real complexity start showing up because you don't really want the full matrix, and also you want PPC64LE sometimes, etc. etc. Point being, the real requirements are more complex then what you do on Travis. > - Easy to test changes before merging (push to your fork on github) Sent a patch to Gerrit, also see thread mentioned above and: https://ovirt-jira.atlassian.net/browse/OVIRT-1013 > - Very nice web ui, e.g. > https://travis-ci.org/oVirt/vdsm/builds/198571421 > https://travis-ci.org/oVirt/vdsm/jobs/198571422 Take a look at 'Jenkins Blue Ocean", we'll deploy that eventually. Then again, the existing Jenkins UI is far more flexible then any of the modern flashy UIs I've seen. I guess this is a KDE v.s. Gnome kind of thing... What really needs to happen is that the relevant info needs to end up in a Gerrit comment. -- Barak Korren bkor...@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra