On Sun, Feb 5, 2017 at 6:25 PM, Nir Soffer <nsoffer@redhat.com> wrote:
On Sun, Feb 5, 2017 at 11:33 AM, Martin Sivak <msivak@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@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@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@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