See comment on #1806.

Looking at the timings, I was going to ask for every commit to trigger the Clang Format check, as it's so fast compared with the builds. So skipping that and running the builds seems counter-intuitive. The CodeQL checks could, perhaps, be skipped - but I don't know how easy it would be to get the scripts to skip just that.

I think that's not related to this PR? I'm only excluding the run of Auto-Build on the change of .md files.

I think that's not related to this PR? I'm only excluding the run of Auto-Build on the change of .md files.

Yes, but that's wrong. The auto-build needs to run if the md files change. Code quality and Jamulus build may not, but the other parts of the run should be needed. So I'd rather this change didn't happen as it gives the wrong direction to the auto-build.

Ok. Currently autobuild = create release (is requested by git tag) + build assets and check the build process via CodeQL. All of this only needs to run if changes are made to the jamulus code, not .md files.

What should autobuild do if we change .md files?

Basically, if the md files don't contribute to what auto build builds, they shouldn't be under change control at all. (At least, not under jamulussoftware/jamulus.)

What do they contribute to the build?

What do they contribute to the build?

As far as I know they do not contribute to the build process. That's why I am suggesting not to run auto build if there's a change in these files. That's exactly what this PR is doing. It is not stopping clang-format though.

the build process.

I said the build, not the process.

Ok. So what’s the "build" and what’s the "process" for you?

Just build = just compiling (qmake && make) or from a broader view compiling + packaging?
Process = creating a release, CodeQl, compiling, packaging, uploading binaries?

The build is what the process of building produces.

Ok. So for you the build is the binary file which gets uploaded at the end. .md files don’t contribute to these files.

Could you please exactly clarify what you want not to be changed. What should still run if you e.g. only fix a typo in README.md? Certainly not the CodeQL scanning, building of binaries, packaging,…

.md files don’t contribute to these files.

OK, so there a some files that should not trigger the autobuild process as they're not in the artifacts the build process produces.

However, I'd rather see an explicitly list of the files than a blanket ban on *.md, as it presumes we will never want to distribute an *.md file with the built artifacts.

If we can base the exclusion on the content of a file (that's under change control and is itself excluded), then that also makes it easier, in future, to add other files.

Yes. Good idea.

I think we could use https://github.com/MarceloPrado/has-changed-path

Mmm... What @MarceloPrado/has-changed-path does is

peter@fs-peter:~/git/Jamulus-wip$ git diff --quiet HEAD~ HEAD ChangeLog; echo $?
1
peter@fs-peter:~/git/Jamulus-wip$ git diff --quiet HEAD~ HEAD '**.md'; echo $?
0
peter@fs-peter:~/git/Jamulus-wip$ git diff --quiet HEAD~ HEAD '**.md' ChangeLog; echo $?
1

So that tells me something...

Let's say I change COMPILING.md, Jamulus.pro and ChangeLog. I'm still going to get told that my commit changed **.md files. But I definitely, definitely, without question, need to run the build because I changed the basic definition of Jamulus - Jamulus.pro - in some way.

OK, so say I have a .buildignore file like (grep extended RE syntax):

^.buildignore$
^ChangeLog$
^.*\.md$

and then I run

$ git diff --name-only a8bcd385..HEAD | wc -l
46
$ git diff --name-only a8bcd385..HEAD | grep -E --file=.buildignore
.github/pull_request_template.md
COMPILING.md
ChangeLog
$ git diff --name-only a8bcd385..HEAD | grep -v -E --file=.buildignore | wc -l
43
$ git diff --name-only a8bcd385..HEAD | grep -q -v -E --file=.buildignore; echo $?
0

0 (true) meaning there were matches - i.e. those 43 lines not excluded.

The actual check would be

$ git diff --name-only HEAD~..HEAD | grep -E --file=.buildignore
ChangeLog
$ git diff --name-only HEAD~..HEAD | grep -q -v -E --file=.buildignore; echo $?
1

1 (false) meaning no files from the last commit were not excluded.

So we could fork has-changed-path and make it do that, instead, I guess (without the echo $? of course). Or add our own.

Or maybe it could just run before the repo checkout step somehow and stop the run (with a "success" value).

Or maybe it could just run before the repo checkout step somehow and stop the run (with a "success" value).

Probably that's the easiest option?

TODO:

• Clarify which files can be excluded (CONTRIBUTING.md, COMPILING.md, SECURITY.md, README.md, RELEASE-PROCESS.md TRANSLATING.md, COPYING (?), /tools/* [at least for now], .gitignore)
• Research how to successfully stop CI
• Write a shell script which aborts the build process if these files were changed
• Close this PR and open a new one

Closing since #1974 should be used as discussion