canonical / sphinx-docs-starter-pack

A documentation starter-pack
https://canonical-starter-pack.readthedocs-hosted.com/
Other
16 stars 43 forks source link

Add a GitHub action for periodically running vale and storing the results #281

Closed k-dimple closed 1 month ago

k-dimple commented 2 months ago

Current automated documentation checks do not include style checks. To include style checks using vale, this PR adds a GitHub action that runs once a week and stores the results in a GitHub artifact that can be downloaded.

Addresses DOCPR-876

k-dimple commented 2 months ago

@SecondSkoll Severity levels? (DOCPR-776 seems to be the wrong one)

@evilnick was there a specific reason for wanting periodic vale checks instead of running them as non-blocking PR actions?

Yes, we could wait for vale to become more stable before including it in our workflows.

SecondSkoll commented 2 months ago

@SecondSkoll Severity levels? (DOCPR-776 seems to be the wrong one)

@evilnick was there a specific reason for wanting periodic vale checks instead of running them as non-blocking PR actions?

Yes, we could wait for vale to become more stable before including it in our workflows.

Quite right, wrong issue. Yes, changing the severity levels will change the output, also any refinements we make after testing. Presumably next cycle will involve some level of optimisation and reworking of rules - otherwise Vale is going to cause a lot of noise.

evilnick commented 2 months ago

I am going to be tweaking the default Vale config this pulse so we can push a v1.0 out. For the purposes of this task though, I think we should pursue periodic executions. The data may be junk for now, but it will be there. The reason for periodic vs PR based run is that, for the metrics and tests we will eventually want snapshots of the existing docs as published. The PR-based rules are so you know what you are adding, the periodics are so we assess state of current published docs. As I say, the data may be junk to begin with, but hopefully that will improve (and we will be able to see that too).

So for example, maybe on a PR the pa11y text complains about something. You may chose to see it as junk, or merge anyhow if it is non blocking. Those tests don't tell us anything about the docs that are published. a recurring task which logs a dozen a11y failures, or broken links is more useful

SecondSkoll commented 2 months ago

I'm going to close this due to our discussion from 2024/09/26. Feel free to reopen this if necessary.

evilnick commented 1 month ago

can we modify this action so it just runs and doesn't store output ( i mean, it can output to the console and we can than see it in the run logs anyhow).

SecondSkoll commented 1 month ago

All changes from main have been merged in to the use-canonical-sphinx-extension branch. It would be great to submit a PR against that branch instead as it's about to become the main branch.

k-dimple commented 1 month ago

Sure, I can submit a PR for it in that branch.