On 28/02/2020 13:46, Michel Dänzer wrote:
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)
Sounds like a good alternative to tags.
-Lionel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
