Don’t run CI if only .md files are pushed

[ann0see]

Has this feature been discussed and generally agreed?

No

Describe the solution you'd like

The CI should not run if only .md files are changed since this is just a waste of ressources.
OBS seems to do it: https://github.com/obsproject/obs-studio/blob/master/.github/workflows/main.yml

[pljones]

Surely things like the deb src file need the updated .md files as well as all the other source? That means running the Debian build, at least.

[ann0see]

Not sure I understand. The deb src file is not created via GH actions, as far as I know?

[pljones]

If we're ever to become the official source of the deb files, rather than relying on them being repacked, then we need to.

[hoffie]

If we're ever to become the official source of the deb files, rather than relying on them being repacked, then we need to.

But would this require that each change of a Github-related file (.github/) or an in-repo documentation (SECURITY.md) must trigger code checks and build artifacts? That is what this PR would stop from working (and therefore make those PRs quicker).

Build artifacts (e.g. when triggered by code changes or tagging) would still include those files, as far as I understand.

[pljones]

The Clang format check runs in under 20 seconds and is run once for the change. So it doesn't seem worth skipping that. The builds take "ages". The CodeQL checks don't take up much of that, from what I'm aware. However, it's not that easy to see, as it's run in the same workflow.

It would be better to split out the Clang format and CodeQL checks into separate workflows triggered only by code changes... but we'd want to make the builds dependent upon Clang format and CodeQL checks passing, if triggered.

[ann0see]

The CodeQL checks don't take up much of that, from what I'm aware.

Yes, they do. If you disable codeql the build is speeded up by a factor of 2 as far as I remember

[ann0see]

It would be better to split out the Clang format and CodeQL checks into separate workflows triggered only by code changes...

They’re already in different files.

[pljones]

They’re already in different files.

The Clang format check is a separate run. It runs once, not six times.

The CodeQL runs for each build. It shouldn't take as long as it does. It takes that long because it duplicates a lot of what else happens, IIRC.

The flow should be:

• prepare
• git export
• Clang format -> if failed, abort run
• <platform-specific compile>
• <platform-specific CodeQL> -> if failed, abort run
• <platform-specific packaging, if its a packaging build>

As far as I remember, what actually happens is

• prepare
• git clone
• Clang format -> if failed, abort run
• <platform-specific compile and (if its a packaging build) platform-specific packaging>
• <platform-specific compile and platform-specific CodeQL> -> if failed, abort run

with that platform-specific compile happening twice.

With my proposed layout, the Clang format check, compile and CodeQL steps could be made dependent upon code changes. Currently, the packaging has to happen whether code is changed or not - and is in the same step as the compile.

[ann0see]

Actually, I think it's even a bit more complicated. On macOS we're doing 3 builds:

1. CodeQl
2. Packaging
3. Legacy packaging

Clang format does not yet abort packaging/CodeQl

We are - as far as I remember - running CodeQl while packaging is done. So except for macOS we're close to the suggested workflow. If that's not the case, please show where we can avoid duplication (except for macOS, ofc.)