Revert ".github: Create lint-rst.yaml"

[bmcustodio]

This reverts commit 6eea0ad, which seems to have broken the build, until it is investigated further.

References #16387.

[qmonnet]

Cc @geyslan for information.

This is not the build, but the GitHub action to invoke the RST linter that currently cause the CI checks to fail. The author of the initial PR seems to have a fix, but at this time it is not clear what that action brings over the rstcheck run that we already had (it seems that both the GH action for rstcheck and rstcheck run in shell scripts were proposed at the same time, and were both accepted (with some delay) and nobody noticed).

Marked for backports because there are pending backports for the initial commits, but it's maybe still time to take the initial commit out of those backports - in which case the current PR won't need to be backported, either.

[geyslan]

Cc @geyslan for information.

This is not the build, but the GitHub action to invoke the RST linter that currently cause the CI checks to fail. The author of the initial PR seems to have a fix, but at this time it is not clear what that action brings over the rstcheck run that we already had (it seems that both the GH action for rstcheck and rstcheck run in shell scripts were proposed at the same time, and were both accepted (with some delay) and nobody noticed).

Marked for backports because there are pending backports for the initial commits, but it's maybe still time to take the initial commit out of those backports - in which case the current PR won't need to be backported, either.

@qmonnet I got it. I was assigned to the #13366 and followed the instructions put there. =)

Well, could you guys please analyze it and let us know if the #16387 will be reverted (as it's already flagged)? Whatever the decision, thanks a million.

[joestringer]

Let's merge this revert so that folks don't get unrelated failures on their PRs.

@geyslan once we've merged this, could you try pulling back in the original commit, fixing up this issue and posting a fresh PR? It looks like you already have some idea in mind about how to fix this.

[qmonnet]

Again, before we get a fresh PR it would be good to see if the new action would bring more checks when compared with the rstcheck run that is already in the tree. No need to work on a fix if it's for a redundant check.

[geyslan]

@qmonnet I agree. Perhaps your solution has already solved the original issue.

[qmonnet]

Looking into this:

• The checks seem to be the same overall, with a few minor differences:

  • They're not integrated the same, yours was a separate GitHub action while I just updated the Documentation/check-build.sh script instead to integrate it into the existing action for documentation checks.
  • I report on the info level (you do error), but specifically exclude a number of messages that we consider as false positives.
  • I pin a version of rstcheck, while you pull the one available from the Ubuntu repo I think.

• The issue you initially wanted to address, Catch malformed releases table before merging #13366, detecting malformed tables like this one is not currently addressed. This is because:

  1. The script does not check the main README.rst, which is not under Documentation/ (but it is easy enough to make the script check it too).
  2. Currently, we explicitly omit the reports on malformed tables. This is because this raises false positives when tables contain substitution references. This is a bug in rstcheck, and there is an open issue on the topic. Once this issue if fixed and a new version is released, we should be able to stop ignoring this warning. Alas I don't have anything better for now. :/

In that context, I don't believe a new action is necessary. But you're welcome to address i. and add the main README.rst to the files we check, if you want.