Add functional labels

[vhirtham]

Since I already saw 2 PRs that were converted to "ready for review" just to run specific CI pipelines, what do you think about adding some functional GitHub labels? To specify what I mean, we already have one: no-changelog-entry-needed . By adding those labels we can enforce to run certain pipelines without the need to convert to "ready for review" or whatever condition is necessary. Think that can become handy. (Not sure if that also works with the directory filters)

I use this already in a private repo and find it quite useful. To distinguish functional labels from other ones, we could use a unified color pattern. I found a black font on a white background to be good since it makes the labels less visible, which should be the case for labels that have no use except for triggering a CI run (my opinion).

[CagtayFabry]

the conversion was only necessary because the PRs already existed and the file filters were active, let's see if it works as intended for new PRs

it would only really be a "run full pytest matrix" label that wee need right? Can you link to an example where this is implemented?
The pytest run is already quite complex with all the existing conditions

[vhirtham]

Here is a snippet from one of my private repos:

if: |
    github.event_name == 'push' ||
    contains(github.event.pull_request.labels.*.name, 'CI_run_warnings_as_errors') ||
    (github.event.pull_request.draft == false && github.base_ref == 'master')

We just need something similar to the third line (second condition). Simply bind it with an "or" to the rest to override all other conditions

[CagtayFabry]

ah I see, sounds good 👍

However I would refrain from putting the labeled, unlabeled event trigger in the pytest PR conditions since this happens way to often
In that case just a dummy push (or while setting up the PR) shouldn't be too much of a hassle

[vhirtham]

ah I see, sounds good 👍

However I would refrain from putting the labeled, unlabeled event trigger in the pytest PR conditions since this happens way to often
In that case just a dummy push (or while setting up the PR) shouldn't be too much of a hassle

Don't know if it is that bad if it triggers more often than needed, but a dummy commit will also do the trick. So fine by me.