Re: [PATCH-for-5.2 2/2] gitlab-ci: Avoid running the EDK2 job when not necessary

[Philippe Mathieu-Daudé]

On 11/10/20 4:35 PM, Daniel P. Berrangé wrote:
> On Tue, Nov 10, 2020 at 01:16:06PM +0100, Philippe Mathieu-Daudé wrote:
>> The EDK2 jobs use the 'changes' keyword, which "makes it
>> possible to define if a job should be created based on files
>> modified by a Git push event." (see [1]). This keyword comes
>> with a warning:
>>
>>   Caution:
>>
>>     In pipelines with sources other than the three above
>>     changes can’t determine if a given file is new or old
>>     and always returns true."
>>
>> In commit 922febe2af we moved the YAML config file from the
>> repository root directory to the .gitlab-ci.d/ directory.
>>
>> We didn't respect the previous warning and disabled the
>> 'changes' filter rule, as the files are now in a (directory)
>> three above the YAML config file.
> 
> This description is a bit wierd. I don't see how the location
> in the directory tree has any relevance here.
> 
> IIUC the caution docs quoted above are referring to what triggered 
> the pipeline. They're saying that if the trigger was not a "branch", 
> "merge request", or "external pull request", then the "changes" rule 
> always evaluates true.
> 
> The "branch" source us a bit wierd though, as I'm not seeing
> how gitlab figures out which commits are "new" to the pipeline
> and thus whether the files were modified or not.
> 
> Strangely qemu-project/qemu CI for master seems to be behaving
> correctly and skipping the jobs.

What about this one?

https://gitlab.com/berrange/qemu/-/jobs/827459510

> 
> Something is fishy here and clearly not working, so clearly
> changes are needed, but the commit message is not explaining
> it for me.
> 
>> This jobs takes ~40min, and needlessly burns the 2000 minutes
>> available to GitLab free users. Follow the recommendations in
>> [3] and disable this job by default (except if we push a tag
>> or the branch contains 'edk2'). Note we do not remove the job
>> from the pipeline, it can still be triggered manually from the
>> WebUI.