GH Actions: Split ci-macos.yml out from tox.yml
mkoeppe opened this issue · 24 comments
When preparing a portability report such as https://groups.google.com/g/sage-release/c/GOGWk66zaCQ/m/dBQww8WNAAAJ, I have found that the output of tox.yml has gotten too big to be comfortably inspected in one go.
So we split out everything macOS into a separate workflow.
Preparation for #33062 and #32570
Depends on #34017
Component: porting
Author: Matthias Koeppe
Branch/Commit: aa25405
Reviewer: Dima Pasechnik
Issue created by migration from https://trac.sagemath.org/ticket/33788
Author: Matthias Koeppe
Description changed:
---
+++
@@ -1,2 +1,5 @@
+When preparing a portability report such as https://groups.google.com/g/sage-release/c/GOGWk66zaCQ/m/dBQww8WNAAAJ, I have found that the output of `tox.yml` has gotten too big to be comfortably inspected in one go.
+So we split out everything macOS into a separate workflow.
+
Preparation for #33062
I think it makes sense to have all them all together in one workflow. Especially with your idea to use stages, it makes sense to have all everything in one workflow since then you can easily wait on previous stages before running stages that run os-unspecific things (like running tests) on the artifacts of the previous stage. In principle, there are also github actions that enable one to wait on other workflows, but they are pretty unreliable in my experience.
If its only for the overview, I would suggest to use the recently introduced feature to generate job summaries to automatically generate the portability report: https://github.blog/2022-05-09-supercharging-github-actions-with-job-summaries/
The runs for different OSes do not need to wait for each other for anything
The dist workflow for example even runs on ubuntu.
Moreover, with a bit of refactoring there doesn't seem to general obstacles why you cannot have the same matrix running across different os.
I feel like it would be helpful to have a general big picture for how to structure the workflows instead of moving them back and forth in the coming months.
I'm the one who monitors these workflow runs when releases are made, so organizing it for my convenience should be a good enough reason.
Replying to @tobiasdiez:
If its only for the overview, I would suggest to use the recently introduced feature to generate job summaries to automatically generate the portability report: https://github.blog/2022-05-09-supercharging-github-actions-with-job-summaries/
Counting green checkmarks is not what takes the time. It's looking at the logs
Replying to @mkoeppe:
Replying to @tobiasdiez:
If its only for the overview, I would suggest to use the recently introduced feature to generate job summaries to automatically generate the portability report: https://github.blog/2022-05-09-supercharging-github-actions-with-job-summaries/
Counting green checkmarks is not what takes the time. It's looking at the logs
You can put in the markdown overview whatever you want, for example the summary of what test failed or at what stage the tests failed etc.
It does look like a nice feature, but I don't plan to work on creating such a report.
Let's get this in please.
Description changed:
---
+++
@@ -1,5 +1,5 @@
When preparing a portability report such as https://groups.google.com/g/sage-release/c/GOGWk66zaCQ/m/dBQww8WNAAAJ, I have found that the output of `tox.yml` has gotten too big to be comfortably inspected in one go.
So we split out everything macOS into a separate workflow.
-Preparation for #33062
+Preparation for #33062 and #32570
I presume it was tested on GH Actions. A link?
lgtm
Changed reviewer from https://github.com/mkoeppe/sage/actions/runs/2611393906, https://github.com/mkoeppe/sage/actions/runs/2611393910 to Dima Pasechnik
Thank you!
Changed branch from u/mkoeppe/gh_actions__split_ci_macos_yml_out_from_tox_yml to aa25405