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.
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 neededThanks 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.
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.
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.
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 -- 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. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9037): https://lists.opendaylight.org/g/Discuss/message/9037 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] -=-=-=-=-=-=-=-=-=-=-=-
OpenPGP_signature.asc
Description: OpenPGP digital signature
