.github/workflows/ci-linux.yml: Fine-tune max-parallel

[mkoeppe]

... for constructive clogging, #36616 (comment)

📝 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

[kwankyu]

In addition to that, I still think "minimal" and others should be put to the queue by smaller chunks, max-parallel 10 or something (instead of current default 30), to allow room for PRs.

But this also seems to depend on how many PR jobs are waiting to get into the queue. If that number is small, perhaps we don't need that adjustment. Let's see.

[github-actions]

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

[kwankyu]

No idea how the specific numbers 8 and 24 are obtained.

Anyway, overall decreasing of max-parallel numbers looks good to me.

[mkoeppe]

Thanks!

[kwankyu]

Blocker?

[mkoeppe]

Sure, to get it merged in the next rc.

[kwankyu]

"default" workflow finished after ~3 hours after release. Now 4 hours have passed since release. But the queue is still clogged with jobs of "standard-pre" and "minimal-pre". Many B&T jobs for PRs are waiting in the queue. We still have this problem.

This PR seems insufficient to solve the problem. How about removing "minimal-pre" jobs from the first batch and putting it after "standard-pre"? Decreasing max-parallel for all jobs except "standard-pre" seems to help. No?

[mkoeppe]

I think a big chunk of extra clogging comes from https://github.com/sagemath/sage/actions/runs/6842482905, a "CI Linux incremental" workflow run with >= 24 parallel jobs.

[mkoeppe]

Hence #36697