[ovirt-devel] Heads up: dropping fcraw jobs from jenkins

[Barak Korren]

On 13 March 2018 at 09:02, Yedidyah Bar David <didi at redhat.com> wrote:
> On Tue, Mar 13, 2018 at 8:43 AM, Barak Korren <bkorren at redhat.com> wrote:
>>
>> On 12 March 2018 at 16:44, Sandro Bonazzola <sbonazzo at redhat.com> wrote:
>>>
>>>
>>>
>>>
>>>
>>> 2018-03-12 15:36 GMT+01:00 Eyal Edri <eedri at redhat.com>:
>>>>
>>>>
>>>>
>>>> On Mon, Mar 12, 2018 at 3:11 PM, Yedidyah Bar David <didi at redhat.com>
>>>> wrote:
>>>>>
>>>>> On Mon, Mar 12, 2018 at 12:50 PM, Nir Soffer <nsoffer at redhat.com> wrote:
>>>>> > On Thu, Mar 8, 2018 at 4:00 PM Sandro Bonazzola <sbonazzo at redhat.com>
>>>>> > wrote:
>>>>> >>
>>>>> >> Following today call, I'm going to push a patch for dropping all
>>>>> >> rawhide
>>>>> >> jobs from jenkins.
>>>>> >> This should help avoiding distractions and reducing patches blocked
>>>>> >> by
>>>>> >> rawhide issues.
>>>>> >
>>>>> >
>>>>> > Hi Sandro,
>>>>> >
>>>>> > I worked hard to get ioprocess and ovirt-imageio working on fcraw, so
>>>>> > this
>>>>> > change will create extra work for me to fix the regressions later when
>>>>> > we
>>>>> > enable fcraw again.
>>>>> >
>>>>> > Please revert the change for the ovirt-imageio and ioprocess projects.
>>>>>
>>>>> I'd like too to keep fcraw, for otopi, now pushed
>>>>> https://gerrit.ovirt.org/88816 .
>>>>>
>>>>> Perhaps for the time being it's best if other projects' maintainers do
>>>>> the same, if they want to, and commit to fixing issues in fcraw quickly
>>>>> (I hope I do...).
>>>>
>>>>
>>>> Maybe its a good oppertunity to move the projects to V2, so the settings
>>>> will be done inside the project itself and not in Jenkisn repo.
>>>> Also, maintainers needs to understand that if fcraw build is failing no
>>>> other distro will be deployed to tested ( as communicated numerous times
>>>> already ), so if you're not sure fcraw will work
>>>> keep it on check-patch only and don't add build-artifacts jobs.
>>>
>>>
>>> Can you point to the documentation for V2?
>>
>>
>> The 1st one is on-the-house ;) Want us to send patches to move otopi to v2?
>
> You know, patches are always welcome :-))
>
> But I can't promise I'll have too much time to work with you on this.
> Before continuing, and even reading the docs: Is it possible to remain in
> V1 for some branches (say, 4.2) and move to V2 for others (master)?

Its possible, as well as having both work side-by-side (and run the
same tests/builds twice on every patch).
But this will make for a confusing UX...

>
> Also, if you ask me, now might be a good time to change our naming.
> While we call our "Build and test standards", _Standards_, I am not aware
> of any other project or CI system that uses them.

We're trying to change that.

> 'automation/' was not
> a good name, as it had high chances to collide with other stuff. Same is
> for 'automation.yaml'. Perhaps rename at least latter to 'oVirt-CI-conf.yaml'
> or something like this? Over time, projects will move to V2 and eventually
> get rid of 'automation/'.

V2 supports several other names for the yaml file, the directory name
can be customized as well.

>
> Alternatively, find if there are any accepted real standards for these things,
> and consider adopting them. I am not aware of any, personally, didn't search.

There are none, everything we`ve found there is a de-facto standard
that is hard-wired to a very specific set of implementation concepts
and technologies (e.g. .travis.yaml and Jenkinsfile) to my knowledge
we`re the only ones that tried to define things in such a way that
enables different implementations.

>
>>
>> Docs are being worked on but in essence V2 makes the UX for gerrit projects
>> similar to the way things have worked for GitHub projects for a while now
>> [1].
>>
>> V2 does provide way more then what is documented there (you need more to be
>> able to cover complex scenarios like supporting specific sets of
>> architectures in specific distributions), but what we have there is enough
>> to get the basic ideas and do initial work.
>>
>> [1]:
>> http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_GitHub/#the-automationyaml-file
>>
>> --
>> Barak Korren
>> RHV DevOps team , RHCE, RHCi
>> Red Hat EMEA
>> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
> --
> Didi



-- 
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted