Reduce workflows on main

[strengejacke]

Given that we usually create PRs before changes enter the main branch, wouldn't it be enough to just run a few checks on push/main, and run all checks only on pull-request/main?

I'd suggest for push/main:

• pkgdown
• win-devel (or release?)
• ubuntu-devel (or release?)
• maybe some more, probably one check-hard-ubuntu-devel?

And for PR/main, all the above checks plus the remaining ones (lintr, HTML, all examples, ...).

This would save some resources.

[strengejacke]

And, given that we sometimes skip tests on linux, sometimes on windows, we should probably run check-hard twice, on win and lin.

[IndrajeetPatil]

Sure, I am fine with running some workflows only on a weekly or monthly basis. We already do this with dev R CMD check.

[strengejacke]

Not sure how to modify the yaml-files so that they only run on PR, not on push to main. Or is it something we do in our repos directly?

[IndrajeetPatil]

Have a look at this PR: easystats/see#340

[strengejacke]

Have a look at this PR: easystats/see#340

scheduled workflows make sense on main, but not for PRs, I'd say. And we need to add windows-devel to "hard" checks, too, though I don't understand the script and how to add win-devel to it.

[IndrajeetPatil]

For more spirited discussion, see:

easystats/dashboard#19

[IndrajeetPatil]

scheduled workflows make sense on main, but not for PRs, I'd say

But I didn't say that. What does it even mean to run a scheduled workflow on a PR?! CRON jobs are always set up on prod, develop, and staging branches, and not on feature branches.

What I was saying was that we run all the workflows:

• always for PRs and
• on a schedule on the default branch

[IndrajeetPatil]

And we need to add windows-devel to "hard" checks, too, though I don't understand the script and how to add win-devel to it

I literally took care of this the next day but you had already removed a bunch of the workflows from the default branches by then across multiple repos 🤷

[IndrajeetPatil]

Also, since what started this whole conversion was sustainability, we already have concurrency in our workflows that cancels in-progress jobs if a new commit appears.

[strengejacke]

removed a bunch of the workflows from the default branches

? I did not change any of the general workflows here. I only added (instead of removing) another workflow, which I use for some of the repos I maintain, because they run checks that were literally run seconds before on PR - and thereby, are not needed.

[IndrajeetPatil]

I did not change any of the general workflows here

You disabled the workflows from running on the default branch, and that's a big change. We track the CI status of our projects using a dashboard that checks the default branch. But since those workflows are no longer run on the default branch for insight, parameters, performance, etc., this part of the dashboard no longer works and, basically, there is no longer a quick way to get a sense of how the organisation-wide workflows are doing.

because they run checks that were literally run seconds before on PR - and thereby, are not needed

I beg to differ with that assessment.

[strengejacke]

etc.,

Not "etc". They're run for every package that I do not maintain (and where I did not change the workflows). :-)