On 2020-02-28 12:02 p.m., Erik Faye-Lund wrote: > On Fri, 2020-02-28 at 10:43 +0000, Daniel Stone wrote: >> On Fri, 28 Feb 2020 at 10:06, Erik Faye-Lund >> <erik.faye-lund@xxxxxxxxxxxxx> wrote: >>> On Fri, 2020-02-28 at 11:40 +0200, Lionel Landwerlin wrote: >>>> Yeah, changes on vulkan drivers or backend compilers should be >>>> fairly >>>> sandboxed. >>>> >>>> We also have tools that only work for intel stuff, that should >>>> never >>>> trigger anything on other people's HW. >>>> >>>> Could something be worked out using the tags? >>> >>> I think so! We have the pre-defined environment variable >>> CI_MERGE_REQUEST_LABELS, and we can do variable conditions: >>> >>> https://docs.gitlab.com/ee/ci/yaml/#onlyvariablesexceptvariables >>> >>> That sounds like a pretty neat middle-ground to me. I just hope >>> that >>> new pipelines are triggered if new labels are added, because not >>> everyone is allowed to set labels, and sometimes people forget... >> >> There's also this which is somewhat more robust: >> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2569 > > I'm not sure it's more robust, but yeah that a useful tool too. > > The reason I'm skeptical about the robustness is that we'll miss > testing if this misses a path. Surely missing a path will be less likely / often to happen compared to an MR missing a label. (Users which aren't members of the project can't even set labels for an MR) -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
