[ovirt-devel] Jenkins jobs ownership

[Barak Korren]

On 5 February 2017 at 19:25, Nir Soffer <nsoffer at redhat.com> wrote:
> On Sun, Feb 5, 2017 at 11:33 AM, Martin Sivak <msivak at 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
bkorren at redhat.com
RHCE, RHCi, RHV-DevOps Team
https://ifireball.wordpress.com/