-
Notifications
You must be signed in to change notification settings - Fork 693
ci: Limit scope of unittest to one python version #2256
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
Conversation
Limits scope of unittesting to one python version for both macOS and Windows. These types of workflows are particularly expensive and take a long time so running them on every PR / every push is a bit wasteful considering the value in signal between different python versions is probably negligible. Signed-off-by: Eli Uriegas <[email protected]> [ghstack-poisoned]
Limits scope of unittesting to one python version for both macOS and Windows. These types of workflows are particularly expensive and take a long time so running them on every PR / every push is a bit wasteful considering the value in signal between different python versions is probably negligible. Signed-off-by: Eli Uriegas <eliuriegasfb.com> ghstack-source-id: 0e44bf8 Pull Request resolved: #2256
Limits scope of unittesting to one python version for both macOS and Windows. These types of workflows are particularly expensive and take a long time so running them on every PR / every push is a bit wasteful considering the value in signal between different python versions is probably negligible. Signed-off-by: Eli Uriegas <eliuriegasfb.com> [ghstack-poisoned]
Limits scope of unittesting to one python version for both macOS and Windows. These types of workflows are particularly expensive and take a long time so running them on every PR / every push is a bit wasteful considering the value in signal between different python versions is probably negligible. Signed-off-by: Eli Uriegas <eliuriegasfb.com> ghstack-source-id: c1d95a5 Pull Request resolved: #2256 Signed-off-by: Eli Uriegas <[email protected]>
@seemethere has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
I just wanted to note that there were cases where Python version mattered in macOS.
It ultimately boils down to how multiprocessing is used.
https://docs.python.org/3/library/multiprocessing.html#contexts-and-start-methods
Changed in version 3.8: On macOS, the spawn start method is now the default. The fork start method should be considered unsafe as it can lead to crashes of the subprocess. See bpo-33725.
However, it is more about how the code is using subprocessing
, (and it still comes back from time to time) so I agree with the point, not providing much signal.
Summary: Pull Request resolved: pytorch#2256 Limits scope of unittesting to one python version for both macOS and Windows. These types of workflows are particularly expensive and take a long time so running them on every PR / every push is a bit wasteful considering the value in signal between different python versions is probably negligible. Signed-off-by: Eli Uriegas <[email protected]> Test Plan: Imported from OSS Reviewed By: mthrok Differential Revision: D34459626 Pulled By: seemethere fbshipit-source-id: 47f5c317027f1b395edf9c1720b1b33ba689cad5
Stack from ghstack:
Limits scope of unittesting to one python version for both macOS and
Windows. These types of workflows are particularly expensive and take a
long time so running them on every PR / every push is a bit wasteful
considering the value in signal between different python versions is
probably negligible.
Signed-off-by: Eli Uriegas [email protected]
Differential Revision: D34459626