PRs with only Markdown changes don't trigger workflows that are required for merging

[bdferris-v2]

Describe the problem

As recently demonstrated in PR #1332 and currently blocking #1330, changes that only update Markdown files (e.g. RULES.md) do not trigger actions / workflows / required checks that are prerequisites for merging. Merging these PRs require a manual override from a repo admi (aka @fredericsimard), which seems heavy weight for simple documentation changes.

This issue tracks potential options for improving this situation.

Suggest a fix or an alternative

No response

[bdferris-v2]

I think there are a couple of options here:

1. We could stick with the status quo. Namely, require a repo admin (currently @fredericsimard) to explicitly merge any documentation-only changes to the repo.
2. We could run all status checks even for documentation changes. This is a bit overkill, especially for the end-to-end and acceptance test workflows. However, given PRs like #1331 to add a unit test checking that docs are in sync and general changes potentially coming from #1324, we'd probably need to enable at least some status checks for docs either way.
3. We could employ some of the strategies identified in Handling skipped but required checks where we'd define parallel workflows for docs only that produce the same named status checks. I think this is potentially doable, but I'd want to refactor our workflows a bit to make this duplication less brittle.

I'm inclined to go with a combination of 2 and 3. Namely, include docs in the existing test_pack_doc.yml workflow and create a parallel workflow for non-code resources duplicating the status checks of acceptance_test.yml and end_to_end.yml.

[fredericsimard]

Just to be certain, do you need my input on this?

[isabelle-dr]

Thank you for opening this issue @bdferris-v2! @fredericsimard I don't think we need your input, but what we decide here might mean we won't need to ping you everytime we want to merge a PR that only contains changes to the documentation :)

I am OK with what you're suggesting. @davidgamez, any particular thoughts?

[davidgamez]

I agree with the options. I think that number 3 is straightforward with no surprises in its implementation.