Re: [PATCH 1/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi everyone,

On 2/29/24 11:02, Maxime Ripard wrote:
On Wed, Feb 28, 2024 at 07:55:25PM -0300, Helen Koike wrote:
Which rating would you select?

4.5 :)

One thing I'm wondering here is how we're going to cope with the
different requirements each user / framework has.

Like, Linus probably want to have a different set of CI before merging a
PR than (say) linux-next does, or stable, or before doing an actual
release.

Similarly, DRM probably has a different set of requirements than
drm-misc, drm-amd or nouveau.

I don't see how the current architecture could accomodate for that. I
know that Gitlab allows to store issues template in a separate repo,
maybe we could ask them to provide a feature where the actions would be
separate from the main repo? That way, any gitlab project could provide
its own set of tests, without conflicting with each others (and we could
still share them if we wanted to)

I know some of use had good relationship with Gitlab, so maybe it would
be worth asking?

GitLab already supports getting the CI YAML from other repos. You can change that in the repo settings.

However, I think a better approach would be *not* to add the .gitlab-ci.yaml file in the root of the source tree, but instead change the very same repo setting to point to a particular entry YAML, *inside* the repo (somewhere under "ci" directory) instead.

This way all the different subtrees can have completely different setup, but some could still use Helen's work and employ the "scenarios" she implemented.

Nick




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux