CI: don't build doc changes

[nephele]

The CI should not "verify" changes that only touch doc/ this is currently just chatter and a false sense of security.

It could make sense to later add a html/css validator (and use doxygen for stuff that needs it)

Building Haiku is not relevant for documentation changes anyhow.

(on a side note: why can't I view CI results without github wanting me to give access to some unrelated repo in my account? That seems really wrong)

[madmax]

While I agree it's wasteful, I don't get the security part. The CI does not verify the changes, but that those changes don't break the build.

I also agree it does make sense to add a target checking the docs specifically, as many other parts outside of docs that are currently not built unless you ask for them, to which this ticket applies as well. And detecting and running all the tests that may apply to the changed code. And a full matrix of compile options: one commonly undetected problem is printf formatting in guarded traces that only work in 32 or 64 bits.

But then I've been running a builder myself for some time and I have not yet added any of that.

[nephele]

I ment security in the sense of someone feeling that "the ci checked it so it's fine" while it isn't the case.

[madmax]

But it's never the case, even for common code. You can be quite sure that when the CI says it's not right, it is not. But the CI saying it's OK gives no guarantees. It's just another data point: it still builds. Even if it did run tests, it could still be wrong due to lack of coverage or any other thing. Not even reviewers giving it the OK is a guarantee.

[nephele]

I know this, as do you. but not everyone who used gerrit has to know that the CI does not do anything with the documentation. that is what i ment with a false sense of security.

[korli]

Maybe [skip ci] in the commit message could simply skip the CI build.