ci: Avoiding linting CONTRIBUTORS.yml

[polarathene]

Description

• The file is managed by the contributors.yml workflow, no need for linting to be triggered on PRs for that change.
• The lint workflow did not seem to trigger which blocked merging of an automated PR update to CONTRIBUTORS.md.

Disregard different feature

NOTE:

• This change technically won't have an effect, as the linting workflow AFAIK is treated as required (mandatory), which according to docs will disregard paths / paths-ignore rules.
• Additionally the GH Actions docs for Required Workflows now states this feature is being deprecated, a similar feature is available but is premium (paid); however the OSS tier we're on may be eligible for that? 🤷‍♂️

The linked blogpost is from Aug 2023, announcing deprecation and shutdown of the feature in October. I could be mistaken if this was the feature used with the linting workflow, I just recall it being managed as a required check status which required authorization to modify the organization settings which @georglauterbach has permissions for.

---

EDIT: Seems like I mixed up a different feature, and this is just the required status check, so we can probably rely on this PR to skip it for the file, which will treat it as successful 👍

[georglauterbach]

So what is achieved by this PR? This PR does not seem to change the status quo at all (at least to me).

[polarathene]

So what is achieved by this PR?

See the first link, there is a lint workflow that wasn't triggered, blocking @casperklein and myself from approving + merging the PR.

The lint workflow isn't relevant to that PR type, so the idea here was to have it ignored which should be an automatic pass (skip) avoiding the concern?

If you disagree that's fine, it's an issue that happens a few times a year and can alternatively be solved by waiting for master to be updated with something else to update the PR branch and that'll trigger the workflow (which we can't do ourselves presently when this bug happens).

[georglauterbach]

The lint workflow isn't relevant to that PR type, so the idea here was to have it ignored which should be an automatic pass (skip) avoiding the concern?

Is this really the case? I mean, is ignoring it an automatic pass?

The issue at hand is that one workflow can not trigger workflows by opening a new PR. But because the linting workflow is required for all PRs, we end up in the situation we're in as of now.

It definitely does not hurt to merge this PR, maybe it even solves our problem. We'll see; I'll have a look at the next PR for contributors.

[polarathene]

Is this really the case? I mean, is ignoring it an automatic pass?

The docs say that, see that last screenshot (with the purple highlight) I shared in the PR description.

The issue at hand is that one workflow can not trigger workflows by opening a new PR. But because the linting workflow is required for all PRs, we end up in the situation we're in as of now.

Ah, that makes sense, thanks :)