Enable conda ci for all PRs and remove experimental label

[tobiasdiez]

Using conda to install all sage dependencies is pretty stable and has been long enough in "experimental mode". We remove here the experimental flag and in order to make sure that the workflow is not breaking enable the conda-ci on all PRs. This also provides a) faster feedback as the whole build+test takes only about 1.5h (which is less time then what only the "incremental build" currently takes) and b) tests that the code is working on all supported python versions. The last remaining failing tests under linux are temporarily disabled in #36372.

📝 Checklist

• The title is concise, informative, and self-explanatory.
• The description explains in detail what this PR is about.
• I have linked a relevant issue or discussion.
• I have created tests covering the changes.
• I have updated the documentation accordingly.

⌛ Dependencies

[mkoeppe]

This also provides a) faster feedback as the whole build+test takes only about 1.5h (which is less time then what only the "incremental build" currently takes)

I don't think this comparison makes sense. The (incremental) Build & Test CI takes long currently because there is no current image on ghcr.io. It is building all the major package upgrades that have happened since 10.2.beta1.

[mkoeppe]

I'm in favor of running the conda ci more often; I agree that this could help with reducing bitrot.

It's probably fine to run it on every PR, but I think it should not launch all 3 Linux and 3 macOS runs immediately. This would seriously clog the macOS pipeline.

Perhaps start with one run first and only launch the others on success?

[tobiasdiez]

Perhaps start with one run first and only launch the others on success?

So limit the number of parallel matrix jobs to say 2, and activate "fail-fast", or did you have something else in mind?

We can also disable the macos workflows for now since they are failing anyway.

[mkoeppe]

Perhaps start with one run first and only launch the others on success?

So limit the number of parallel matrix jobs to say 2, and activate "fail-fast", or did you have something else in mind?

Sure, that sounds fine.

We can also disable the macos workflows for now since they are failing anyway.

That would not help. As you already know, #35593 fixes the macos runs, so it could be merged simultaneously if not unforeseen obstacles arise.

[tobiasdiez]

Perhaps start with one run first and only launch the others on success?

So limit the number of parallel matrix jobs to say 2, and activate "fail-fast", or did you have something else in mind?

Sure, that sounds fine.

Implemented.

[mkoeppe]

Thanks, looking good.

[github-actions]

Documentation preview for this PR (built with commit e7d0a44; changes) is ready! 🎉

[tobiasdiez]

Thanks for the positive review!