Hi,
Currently each patch submission automatically starts two jenkins jobs for cloning, building, running tests and static checks. The longest of the two jobs can run for 30mn - 1h depending on server load. A 10 patches stack queues as many of such jobs and it can be a long process to get all votes with a significant load applied to the servers. Along with this the Allow-CI+1 label can be used by maintainers to re-trigger a job either because it failed, or the results/logs were flushed.
Per discussion with various stakeholders we come to a conclusion it would be preferable to only use the Allow-CI label and discard the automatic trigger for each and every patch. Similarly to TF-A, a change submitted by a developer requires a maintainer to apply the Allow-CI+1 label to build and run tests. For a large patch stack, the expectation is at least the top patch must pass the CI run before merging, but not necessarily all intermediate patches. It's the maintainer discretion to apply the label at different places in the patch stack to get intermediate results as required.
I intend to submit a change shortly to adopt this new policy. Let me know if any concern.
Regards, Olivier.
Hi Olivier, sorry for the dumb question, but what is the policy w.r.t fixing issues such as those from clang tidy or formatting issues that may occur in any patch? Should they be fixed in the relevant patch or can it be fixed at the top? Same with test failure caused by an in between patch? Presumably everything can be fixed at the top of the patch stack as opposed to fixing in the patch itself? Or did you intend it a different way?
Sent from my iPhone
On Jan 11, 2023, at 12:43 AM, Olivier Deprez via Hafnium hafnium@lists.trustedfirmware.org wrote:
Hi,
Currently each patch submission automatically starts two jenkins jobs for cloning, building, running tests and static checks. The longest of the two jobs can run for 30mn - 1h depending on server load. A 10 patches stack queues as many of such jobs and it can be a long process to get all votes with a significant load applied to the servers. Along with this the Allow-CI+1 label can be used by maintainers to re-trigger a job either because it failed, or the results/logs were flushed.
Per discussion with various stakeholders we come to a conclusion it would be preferable to only use the Allow-CI label and discard the automatic trigger for each and every patch. Similarly to TF-A, a change submitted by a developer requires a maintainer to apply the Allow-CI+1 label to build and run tests. For a large patch stack, the expectation is at least the top patch must pass the CI run before merging, but not necessarily all intermediate patches. It's the maintainer discretion to apply the label at different places in the patch stack to get intermediate results as required.
I intend to submit a change shortly to adopt this new policy. Let me know if any concern.
Regards, Olivier.
-- Hafnium mailing list -- hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.org
Hi Raghu,
Good observation. For now, if possible, I'd say it's preferable to fix issues in individual changes. Somehow same policy as TF-A's We're exploring options to split the CI label into Allow CI+1/Allow-CI+2 where Alllow-CI+1 would only lint check and Allow-CI+2 build & run.
Regards, Olivier.
________________________________ From: Raghupathy Krishnamurthy raghu.ncstate@icloud.com Sent: 12 January 2023 02:13 To: Olivier Deprez Olivier.Deprez@arm.com Cc: hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Subject: Re: [Hafnium] Hafnium CI policy change
Hi Olivier, sorry for the dumb question, but what is the policy w.r.t fixing issues such as those from clang tidy or formatting issues that may occur in any patch? Should they be fixed in the relevant patch or can it be fixed at the top? Same with test failure caused by an in between patch? Presumably everything can be fixed at the top of the patch stack as opposed to fixing in the patch itself? Or did you intend it a different way?
Sent from my iPhone
On Jan 11, 2023, at 12:43 AM, Olivier Deprez via Hafnium hafnium@lists.trustedfirmware.org wrote:
Hi,
Currently each patch submission automatically starts two jenkins jobs for cloning, building, running tests and static checks. The longest of the two jobs can run for 30mn - 1h depending on server load. A 10 patches stack queues as many of such jobs and it can be a long process to get all votes with a significant load applied to the servers. Along with this the Allow-CI+1 label can be used by maintainers to re-trigger a job either because it failed, or the results/logs were flushed.
Per discussion with various stakeholders we come to a conclusion it would be preferable to only use the Allow-CI label and discard the automatic trigger for each and every patch. Similarly to TF-A, a change submitted by a developer requires a maintainer to apply the Allow-CI+1 label to build and run tests. For a large patch stack, the expectation is at least the top patch must pass the CI run before merging, but not necessarily all intermediate patches. It's the maintainer discretion to apply the label at different places in the patch stack to get intermediate results as required.
I intend to submit a change shortly to adopt this new policy. Let me know if any concern.
Regards, Olivier.
-- Hafnium mailing list -- hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.org
hafnium@lists.trustedfirmware.org
-
Olivier Deprez -
Raghupathy Krishnamurthy