search

jbms / sphinx-immaterial

Adaptation of the popular mkdocs-material material design theme to the sphinx documentation system
https://jbms.github.io/sphinx-immaterial/
Other
195 stars 31 forks source link

ci: schedule twice a month #219

Closed umarcor closed 1 year ago

umarcor commented 1 year ago

Since sphinx-immaterial has a bunch of dependencies, the package can break despite not making any modification to the sources. Actually, software nowadays tends to break unless it is continuously maintained.

Since this repo was not modified in a month, CI was not triggered. The readme shows a green shield/badge. However, the fact is that CI is currently broken.

This PR adds an schedule trigger to the build workflow in order to ensure that breaking changes in the dependencies are caught soon, regardless of the activity in this repo.

2bndy5 commented 1 year ago

However, the fact is that CI is currently broken.

How so?

FYI, Github auto-disables scheduled CI workflows if there hasn't been activity on the repo in a month (speaking from experience). So, I'm not sure this is the solution you seek.

2bndy5 commented 1 year ago

I already have the CI setup to respond to manual triggers: image

  1. select the build workflow
  2. open the "run workflow" dropdown
  3. select the desired branch and trigger the run

If your fork is setup to use the CI, then this should be possible from your fork as well.

2bndy5 commented 1 year ago

However, the fact is that CI is currently broken.

How so?

Oh, I see a recent update to pylint has caused some newer errors to occur... This is why I prefer to use pre-commit to manage dev dependencies' version. Recently, I've been trying out ruff as a much faster alternative to pylint.

umarcor commented 1 year ago

However, the fact is that CI is currently broken.

How so?

New releases of pylint and black. Need to pin them to <2.16.0 and <23.1.0, respectively, for the current main to pass CI. See https://github.com/antmicro/sphinx-immaterial/commit/3d754e3a2b2de2e329e9c3397f0906e5c0e0ec8d and https://github.com/antmicro/sphinx-immaterial/commit/bd9907dc55fd5ddc6b7e15afc959f7f314bddd47.

FYI, Github auto-disables scheduled CI workflows if there hasn't been activity on the repo in a month (speaking from experience). So, I'm not sure this is the solution you seek.

That's after 60 days of inactivity. Not the case here.

Actually, this PR is meant for us to be aware of broken stuff sooner than 60 days. So, ideally, we would never reach that auto-disabling unless there is no change in the stack for 2 months.

umarcor commented 1 year ago

If your fork is setup to use the CI, then this should be possible from your fork as well.

Yes, that feature works on forks as well. However, we do also have scheduled runs, not to rely on humans manually triggering the runs. That's what we would like to upstream here.

2bndy5 commented 1 year ago

I would still prefer to enact pre-commit to avoid problems with new releases from dev tools (like mypy, black, pylint). That way we can locally use pre-commit run to run the python dev tools (similar to this repo's npm run check). Then the dev tools' versions can also be upgraded all at once with pre-commit autoupdate.

umarcor commented 1 year ago

@2bndy5 while I agree it would be interesting to use pre-commit (or any other similar approach) in order to make it easier for developers to bump dependencies, that is unrelated to the problem this issue is about: we know that CI is broken but this repo is showing all green results because no human took any action yet. The solution(s) you propose:

1) Involve human action, so would not fix the problem. Actually, we both acknowledged the problem, and still any other user/visitor will be unaware until they try to build/run it themselves, because the state in the repo will not change until some human makes it explicitly. 2) Are focused on fixing one particular type of issue that can make CI go red. This issue is not about fixing the cause of the problems, but about being aware that something needs to be fixed. For instance, since -latest environments are used, those will eventually break CI as well. pre-commit is useless in that case.

Hence, I suggest to open a different issue for discussing pre-commit or other similar features for automating dependency bumping. We can focus here on CI being informative.

2bndy5 commented 1 year ago

The CI's steps about python linting and format checks may be unsuccessful, but that doesn't mean that building/installing from source will fail. So, the badge on the README isn't really a good indication of viability.

umarcor commented 1 year ago

@2bndy5, agree. However, as said, this issue is not about the specific reasons that made CI fail, but about catching any.

umarcor commented 1 year ago

We can have a separated issue to discuss splitting linting, testing and building to have independent shields/badges, should that be interesting.

2bndy5 commented 1 year ago

Should probably make the trigger weekly or monthly. Daily triggered CI is better for projects with paying customers.

The last thing I want on jbms's plate is a daily CI failed notification when time/priorities don't permit the required human interaction to address the failure.

umarcor commented 1 year ago

I updated this PR to run twice a month (on the first and 16th).