On Sun, Feb 5, 2017 at 6:25 PM, Nir Soffer <nsoffer(a)redhat.com> wrote:
On Sun, Feb 5, 2017 at 11:33 AM, Martin Sivak
<msivak(a)redhat.com> wrote:
>> A repo where I do not have commit rights means I can't take full
responsibility.
>> A repo that is not atomically synchronized with my sources means I
>> can't take full responsibility.
>
> Having said that, I would be perfectly fine with a single repository
> that tracks the release configuration, but only if it also held the
> git repository link and hash/branch name that is supposed to be
> released. It would be in some way a "distgit repo". Something like
> Sandro has for builds.
>
> [ovirt-4.0.x-ci]
>
git://gerrit.ovirt.org/project.git#ovirt-4.0.x
>
git://gerrit.ovirt.org/project2.git#v4.0.x
>
git://github.com/Me/repo#master
>
> [ovirt-4.0.6]
>
git://gerrit.ovirt.org/project.git#ovirt-4.0.6
>
git://gerrit.ovirt.org/project2.git#v4.0.6
>
http://github.com/Me/repo/releases/x.y.z.zip
>
> Any release would then be reviewed by the CI team and that would be
> fine for me. It would allow any branch name or versioning convention
> and would not pollute the sources. It would also be gerrit agnostic.
Well said!
May pain points with jenkins project:
- No documentation
- The format is not stable, each time you edit the format is different
- 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
- The project format is full of duplication
- No commit right, cannot be responsible for something I cannot change
Compare with travis:
- Everting defined in *my* project in .travis.yml
- Configuration format is well documented
https://docs.travis-ci.com/
- 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
- Easy to test changes before merging (push to your fork on github)
- Very nice web ui, e.g.
https://travis-ci.org/oVirt/vdsm/builds/198571421
https://travis-ci.org/oVirt/vdsm/jobs/198571422
I've no strong feelings on this subject. I personally don't know travis so
I can't compare it to anything else.
I'm a jenkins Standard-CI user and I tend to be happy with what we have.
That said, despite I would prefer all ovirt projects to be aligned with the
same workflow, I'm perfectly fine with whatever CI testing / building
system is implemented or used for each project provided that:
- it works
- it produces rpms which can be added to ovirt-system-test for functional
testing
- it produces source archives which can be published on release
- it produces rpms which can be installed on release for all supported
platforms and arches.
- it doesn't require creative ways to get artifacts to be released
Nir
>
> Martin
>
>
> On Sun, Feb 5, 2017 at 10:17 AM, Martin Sivak <msivak(a)redhat.com> wrote:
>> Hi,
>>
>>> The fact that this is specified in the 'jenkins' repo **does not
place
>>> this outside the maintainers` responsibility**.
>>
>> A repo where I do not have commit rights means I can't take full
responsibility.
>> A repo that is not atomically synchronized with my sources means I
>> can't take full responsibility.
>>
>>> We actually have an initiative to move this information to the project
>>> repos. I've started with asking on devel list about how to specify
>>> this as part of Standard-CI [1]. But have received little topical
>>> response so far.
>>> [1]:
http://lists.ovirt.org/pipermail/devel/2017-January/029161.html
>>
>> You've got enough responses already to propose a different schema than
>> fixed branch names. Just give us a config file. Seriously, stop
>> reinventing the wheel and take a look at how others are doing it
>> (distgit, travis, tito, ...).
>>
>> Martin
>>
>>>
>>> --
>>> Barak Korren
>>> bkorren(a)redhat.com
>>> RHCE, RHCi, RHV-DevOps Team
>>>
https://ifireball.wordpress.com/
>>> _______________________________________________
>>> Devel mailing list
>>> Devel(a)ovirt.org
>>>
http://lists.ovirt.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
>
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at
redhat.com