Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GH Actions: Split ci-macos.yml out from tox.yml #33788

Closed
mkoeppe opened this issue May 3, 2022 · 24 comments
Closed

GH Actions: Split ci-macos.yml out from tox.yml #33788

mkoeppe opened this issue May 3, 2022 · 24 comments

Comments

@mkoeppe
Copy link
Member

mkoeppe commented May 3, 2022

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

CC: @dimpase @kliem

Component: porting

Author: Matthias Koeppe

Branch/Commit: aa25405

Reviewer: Dima Pasechnik

Issue created by migration from https://trac.sagemath.org/ticket/33788

@mkoeppe mkoeppe added this to the sage-9.6 milestone May 3, 2022
@mkoeppe
Copy link
Member Author

mkoeppe commented May 3, 2022

@mkoeppe
Copy link
Member Author

mkoeppe commented May 3, 2022

Commit: b7341c2

@mkoeppe
Copy link
Member Author

mkoeppe commented May 3, 2022

New commits:

60adee6.github/workflows/tox.yml: Fix test of optional/experimental packages
c79f735Merge #33755
b7341c2.github/workflows/ci-macos.yml: Split out from tox.yml

@mkoeppe
Copy link
Member Author

mkoeppe commented May 3, 2022

Author: Matthias Koeppe

@mkoeppe

This comment has been minimized.

@mkoeppe mkoeppe modified the milestones: sage-9.6, sage-9.7 May 3, 2022
@tobiasdiez
Copy link
Contributor

comment:5

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/

@mkoeppe
Copy link
Member Author

mkoeppe commented May 10, 2022

comment:6

The runs for different OSes do not need to wait for each other for anything

@tobiasdiez
Copy link
Contributor

comment:7

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.

@mkoeppe
Copy link
Member Author

mkoeppe commented May 11, 2022

comment:8

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.

@mkoeppe
Copy link
Member Author

mkoeppe commented May 11, 2022

comment:9

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

@tobiasdiez
Copy link
Contributor

comment:10

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.

@mkoeppe
Copy link
Member Author

mkoeppe commented May 13, 2022

comment:11

It does look like a nice feature, but I don't plan to work on creating such a report.

@mkoeppe
Copy link
Member Author

mkoeppe commented Jul 2, 2022

Changed dependencies from #33755 to #34017

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Jul 2, 2022

Changed commit from b7341c2 to aa25405

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Jul 2, 2022

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

7140efa.github/workflows/ci-macos.yml: Split out from tox.yml
58d62f4build/bin/write-dockerfile.sh: ADD src/VERSION.txt
aa25405Merge #34017

@mkoeppe
Copy link
Member Author

mkoeppe commented Jul 2, 2022

comment:14

Let's get this in please.

@mkoeppe

This comment has been minimized.

@dimpase
Copy link
Member

dimpase commented Jul 4, 2022

comment:16

I presume it was tested on GH Actions. A link?

@mkoeppe
Copy link
Member Author

mkoeppe commented Jul 4, 2022

comment:17

Testing in a branch with #34110

@dimpase
Copy link
Member

dimpase commented Jul 8, 2022

comment:18

lgtm

@dimpase
Copy link
Member

dimpase commented Jul 8, 2022

@mkoeppe
Copy link
Member Author

mkoeppe commented Jul 8, 2022

comment:19

Thank you!

@vbraun
Copy link
Member

vbraun commented Jul 9, 2022

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants