Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

[Lionel Landwerlin <lionel.g.landwerlin@intel.com>]

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@collabora.com> 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

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx