Reduce the computational expenses of the automated GitHub Workflows

[mpvanderschelling]

The problem

The automated GitHub workflows need some modification to address the following

• We should minimize the number of minutes that are used with GitHub Workflows so that we don't reach the limit before the end of the month.

As the bessagroup account is shared, we should be mindful about this
At the moment, if a pull request is active on either one of the pr/** branches or the main branch, everytime a commit is made, the automated tests are run. These is still a skimmed down version of the tests (only run on Linux + 1 Python version), but it is redundant to run it for every commit.

Proposal

Automated tests should be run only in the following scenarios:

• creation of pull request from issue branch to pr/** (2)
• creation of pull request from pr/** to main (1)
• about to merge to from issue branch to pr/** (2)
• about to merge to from pr/** to main (1)
• after merging to main (all tests to show reliability of the code to users) (1) (3)

How the 'about to merge' trigger might be implemented is still under investigation.

Type of tests

Without going in to much detail, we consider the following test suites:
(1) full test suite (all tests, all major OS, Python 3.7+)
(2) smoke tests (only computationally inexpensive tests, only Linux, Python 3.8)
(3) building sphinx-doc and committing to gh-pages branches for GitHub pages

[mpvanderschelling]

@BernardoFerreira ; can you take a look at the problem description and add anything that you think might be necessary to address this issue ?

[mpvanderschelling]

Automated triage note (reviewed by maintainer @mpvanderschelling before posting):
Code-level check against develop (commit 547f0d7). Please correct anything I've gotten wrong.

Status on develop: Workflows have changed; the original proposal needs re-grounding.

Where the relevant code lives now:

• .github/workflows/:
  • build_docs.yml
  • crw.yml
  • pull_request.yml
  • release.yml

Root cause / analysis:
The branching scheme described in the original issue (pr/** branches gated to main) does not match what I see today — there's no pr/** branch policy anymore; the active development branch is develop. So the specific "creation of PR from pr/** to main" trigger doesn't apply.

That said, the intent (don't burn shared-org Action minutes on every commit) is still valid. Worth verifying:

• Does pull_request.yml run the full matrix on every push, or only on PR open/sync?
• Does build_docs.yml build on every commit to develop?
• What's crw.yml for?

Without that info, I can't propose a concrete change.

Suggested fix (sketch, not a patch):

• Audit each workflow file: list its on: triggers and the matrix size.
• If pull_request.yml runs on push to feature branches, switch to pull_request events only (open / sync / reopen) and rely on branch-protection settings instead.
• Cache pip/uv to shorten run time per job.
• For matrix size: keep Linux × Py3.10 as the smoke matrix; only run the full matrix on PRs targeting main.

Recommended action: Keep open, label ci. I can re-scope the proposal once you confirm the current Action minutes you're paying.