Thanks again Andrew. Here are my comments inline. Hope this helps BR Guillaume
> -----Message d'origine----- > De : Andrew Grimberg <agrimb...@linuxfoundation.org> > Envoyé : mercredi 15 novembre 2023 19:57 > À : LAMBERT Guillaume INNOV/NET <guillaume.lamb...@orange.com>; > Robert Varga <n...@hq.sk>; OpenDaylight Discuss > <discuss@lists.opendaylight.org>; OpenDaylight Dev > <d...@lists.opendaylight.org>; t...@lists.opendaylight.org > Objet : Re: [OpenDaylight TSC] Gerrit verify changes > > See inline, > > On 11/15/23 07:22, guillaume.lamb...@orange.com wrote: > > Thanks Andy for the answers. You can find my answers & comments > below. > > > > Hope this helps > > BR > > Guillaume > > > > -----Message d'origine----- > > De : Andrew Grimberg <agrimb...@linuxfoundation.org> Envoyé : > mercredi > > 15 novembre 2023 15:27 À : LAMBERT Guillaume INNOV/NET > > <guillaume.lamb...@orange.com>; Robert Varga <n...@hq.sk>; > > OpenDaylight Discuss <discuss@lists.opendaylight.org>; OpenDaylight > > Dev <d...@lists.opendaylight.org>; t...@lists.opendaylight.org Objet : > > Re: [OpenDaylight TSC] Gerrit verify changes > > > > On 11/14/23 07:50, guillaume.lamb...@orange.com wrote: > > > > --[snip]-- > > > >>> Note the relation chain of > https://git.opendaylight.org/gerrit/c/transportpce/+/108417 blocked by > Jenkins poor SLA at the moment it was pushed. > >>> It is now ready but we ended up with this particular change that was > >>> ready before the migration and that is not mergeable anymore because > of the absence of the GHA verified +1 It now that blocks the rest of the > chain... > > > >> Please note that 'recheck' and 'remerge' comment triggers work on the > GHA jobs as well, including the required one. I just did a 'recheck' on your > linked change and it passed the GHA in less than a minute. As such, this > change is now unblocked, though Jenkins did remove its vote as it restarted > it's verify job, but I > see that you voted a Verified+1 so it's still > submittable. > > > > Noticed. It seems to work quite well. Thank you for having taken care of it. > > Do you think it would be possible to create a specific trigger similar to > "recheck" only for GHA to avoid relaunching all Jenkins job ? > > Sure, what keyword would you like :) 'rerun-gha'? Please note that anything > with 'recheck' in it will also trigger the Jenkins jobs because of how the > comment trigger works with Jenkins. > [GL] 'rerun-gha' would suit perfectly as far as I am concerned. Thanks for this proposal. > >>> What are the guarantees that the GHA SLA be better ? > >>> If not, it will just worsen this kind of issue. > > > >> We can't give an SLA on another vendors system outside of what they > already offer. What we can state is that in general jobs are more responsive > and faster. That being said, just like any CI system, they run into issues. I > know y'all don't usually see to many with Jenkins and we know that GHA > tends to have a bit > >more stability issues than our Jenkins setups, it is on > the whole a better CI platform for most types of jobs given the following: > > > >> * quick job response > >> * large catalog of pre-made actions that can be utilized > >> * easy ability to put many portions of workflows into a parallel job > >> configuration > >> * Workflows live with the repository itself instead of in a separate repo > (thought this does mean that you can end up with conformance drift across > projects but that can be mitigated with: > >> * Resuable workflows work very similar to JJB templates allowing > >> standardization of jobs but with the flexibility of keeping some jobs > >> on older versions if needed > > > > Thanks for this precious feedback. I understand there is a good chance it > may improve the situation, which is good news. > > Though, I don't think it changes the problem underneath. If the SLA cannot > be guaranteed, we still may face downtimes. > > I'll point out we don't guarantee an SLA on the Jenkins environment either. > > > And with such an enforcement on GHA verified +1 , there would be no way > for committers to force a merge, even if they performed all tests locally to > ensure it is safe. > > While I understand this sentiment, we've had far too many instances where > committers ignored or didn't even wait for CI to validate on INFO.yaml > changes which have caused many problems for those project and for RelEng. > This is, unfortunately, one of those cases of a few too many rotten apples > spoiling it for everyone. We just can't allow anyone that right anymore when > it comes to the configuration files that actually drive access control. > [GL] I was contributing before INFO.yaml were introduced and I totally understand your concern too. I agree many contributors don't handle it properly. But what about all the other ones ? Should we really cut the whole tree because of a few rotten apples ? AFAIK, this file was introduced only to ease the LFN management of Gerrit rights. IMO we should bother contributors at least as possible with such purely LFN sysadmin concerns. So I am not convinced at all we need to check this file at every change. Jenkins allow to check the existence or a modification of a single file and such a job could be run only when this condition is met. I would be surprised GHA doesn't handle this too. But if not, why not running this job separately once a week ? Is this INFO.yaml used so often by LFN process ? I guess this is mostly to reconfigure Gerrit rights, isn't it? My opinion is that all these INFO.yaml files are likely not at their right place at the root of every project repo. IMO, they'd better all be together in a separate DB. I would suggest a specific repository that lists every projects and where TSC members have the +2/verified +1 since every committers' elections must be validated by the TSC. This would avoid many caveats and ease many process. > > Personally, for this sole reason, I am reluctant to migrate all jobs from > Jenkins to GHA. But anyway, let's assume we do it. > > Please note that there are two separate types of GHA checks in play here. > The "required" checks which are driven by the new .github repository. These > are the checks (currently just INFO.yaml validation) that are the non- > overridable checks. > > Then there are the repository checks. Those _would_ be overridable if they > exist. > > To be specific the vote from `ODL Required.GHA` is the one that's required. > For repositories that have GHA jobs defined you'll also find `ODL GitHub > Actions` as a voting reviewer. That account _is_ overrideable, just like the > Jenkins vote currently is. > [GL] Thanks for this clarification. It helped me a lot to better understand the direction you're aiming. I was actually confusing both in my question. > > Is there any pointer on how to migrate current Jenkins profile to GHA ? > > The gerrit-to-platform (the system we developed that is driving this) > documentation lives at [0] with the GitHub specific workflow documentation > at [1]. > > We have many examples now of how to utilize GHA with Gerrit. You can look > in the releng/builder repository itself under .github/workflows for examples > of how we're using it to validate various Jenkins configuration instead of > instantiating jobs in Jenkins for it now. > > At present we've got 3 different workflows defined there: > > gerrit-ci-management-merge.yaml which is the JJB merge job and applies JJB > changes to Jenkins itself. This runs significantly faster in GHA and has been > consistently less likely to get stuck there > > gerrit-ci-management-novote-verify.yaml is a non-voting (info only) > workflow set > > gerrit-verify.yaml is the voting workflow and has several jobs defined in it > so > that you can see how to package up multiple jobs that should vote. > [GL] Thanks again. I will look at this carefully. > > As you may know, we intensively use the tox profile since tox offers a > convenient portable solution that allows us to do concurrency. > > We also use tox in a lot of our work. For instance, gerrit-to-platform does so > as well. This is hosted out of the LF Gerrit instance and you can peruse the > GitHub mirror at [2]. This is probably one of our more complex configurations > right now as it also has a release workflow that gets triggered when a tag is > pushed to the repository. The gerrit-verify workflow also currently has an > example of how you can break apart tox runs into their own parallel jobs as > we have a pre-commit environment in our tox that we run separately and > don't want to run as part of the main body of tox jobs. > > [0] > https://docs.releng.linuxfoundation.org/projects/gerrit-to- > platform/en/stable/index.html > [1] > https://docs.releng.linuxfoundation.org/projects/gerrit-to- > platform/en/stable/readme.html#github-workflow-configuration > [2] https://github.com/lfit/releng-gerrit_to_platform > [GL] Thanks for all these pointer too. I definitely need to have a look at it too. > -- > Andrew J Grimberg > Senior Manager, Release Engineering > The Linux Foundation > > NOTICE: The Linux Foundation supports their employees with flexible work > hours. If you recieve mail from me outside of standard business hours please > be aware that I do not expect a response until the next standard business > day. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9039): https://lists.opendaylight.org/g/Discuss/message/9039 Mute This Topic: https://lists.opendaylight.org/mt/102585993/21656 Group Owner: discuss+ow...@lists.opendaylight.org Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
