Save minutes by avoiding duplicate test runs

[glatterf42]

This PR removes the trigger for CI runs on pushed to main to avoid duplicate test runs. This avoids duplicate runs.

In order for this to work properly, we should make sure that

• [x] main can only be reached via PRs
• [x] PRs need to be up to date with main
• [x] PRs require several tests to be successful before merging

We might also want to

• [x] expand the number of tests we require to be successful

All of which can be done via the settings -> branches.

For now, we require the py3.12 checks for macos, ubuntu, and windows to be successful.

How to review

• Read the diff and note that the CI checks all pass.

PR checklist

• [x] Continuous integration checks all ✅
• ~[ ] Add or expand tests; coverage checks both ✅~ Just changing how often tests are run.
• ~[ ] Add, expand, or update documentation.~ Just changing how often tests are run.
• ~[ ] Update release notes.~ Just changing how often tests are run.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 98.9%. Comparing base (4119b93) to head (c3a7153).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #515 +/- ## ===================================== Coverage 98.9% 98.9% ===================================== Files 44 44 Lines 4804 4804 ===================================== Hits 4754 4754 Misses 50 50 ```

[khaeru]

Some notes for this and the parallel PRs iiasa/message_ix#785, iiasa/message-ix-models#150, iiasa/message_data#527:

• Others settings that currently differ, which we could consider aligning:
  • Require 1+ approving reviews.
  • RTD build as a required check.

• Specifically related to https://github.com/iiasa/message-ix-models/pull/150#issuecomment-1910088126, it might be possible to:

  • force actions/setup-python to install dev builds for prerelease versions of Python; for example 3.13.0-alpha.3 etc.
  • Allow these jobs to "xfail"; that is, possibly fail without impacting the overall check suite.

  In practice, we will always lag the latest Python: for instance, the moment Python 3.13 is released, some of our dependencies will not be installable on that version for various reasons. But such jobs could allow us to automatically monitor compatibility with newer versions of Python and simply notice (by looking at scheduled runs) when that compatibility is achieved.

  IMO this is low priority, since this doesn't cost us a lot of time currently.

[khaeru]

@glatterf42 should we merge this? Anything else to be done?

[glatterf42]

I think it's good to go :)