summaryrefslogtreecommitdiff
path: root/.github/workflows/macos_unit_tests.yaml
AgeCommit message (Collapse)AuthorFilesLines
2020-12-22add mypy to style checks; rename `spack flake8` to `spack style` (#20384)Tom Scogland1-1/+1
I lost my mind a bit after getting the completion stuff working and decided to get Mypy working for spack as well. This adds a `.mypy.ini` that checks all of the spack and llnl modules, though not yet packages, and fixes all of the identified missing types and type issues for the spack library. In addition to these changes, this includes: * rename `spack flake8` to `spack style` Aliases flake8 to style, and just runs flake8 as before, but with a warning. The style command runs both `flake8` and `mypy`, in sequence. Added --no-<tool> options to turn off one or the other, they are on by default. Fixed two issues caught by the tools. * stub typing module for python2.x We don't support typing in Spack for python 2.x. To allow 2.x to support `import typing` and `from typing import ...` without a try/except dance to support old versions, this adds a stub module *just* for python 2.x. Doing it this way means we can only reliably use all type hints in python3.7+, and mypi.ini has been updated to reflect that. * add non-default black check to spack style This is a first step to requiring black. It doesn't enforce it by default, but it will check it if requested. Currently enforcing the line length of 79 since that's what flake8 requires, but it's a bit odd for a black formatted project to be quite that narrow. All settings are in the style command since spack has no pyproject.toml and I don't want to add one until more discussion happens. Also re-format `style.py` since it no longer passed the black style check with the new length. * use style check in github action Update the style and docs action to use `spack style`, adding in mypy and black to the action even if it isn't running black right now.
2020-11-18spack test (#15702)Greg Becker1-1/+1
Users can add test() methods to their packages to run smoke tests on installations with the new `spack test` command (the old `spack test` is now `spack unit-test`). spack test is environment-aware, so you can `spack install` an environment and then run `spack test run` to run smoke tests on all of its packages. Historical test logs can be perused with `spack test results`. Generic smoke tests for MPI implementations, C, C++, and Fortran compilers as well as specific smoke tests for 18 packages. Inside the test method, individual tests can be run separately (and continue to run best-effort after a test failure) using the `run_test` method. The `run_test` method encapsulates finding test executables, running and checking return codes, checking output, and error handling. This handles the following trickier aspects of testing with direct support in Spack's package API: - [x] Caching source or intermediate build files at build time for use at test time. - [x] Test dependencies, - [x] packages that require a compiler for testing (such as library only packages). See the packaging guide for more details on using Spack testing support. Included is support for package.py files for virtual packages. This does not change the Spack interface, but is a major change in internals. Co-authored-by: Tamara Dahlgren <dahlgren1@llnl.gov> Co-authored-by: wspear <wjspear@gmail.com> Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
2020-11-12run unit tests on 3.8 only for Mac OS vs. both 3.8 and 3.9 (#19889)Peter Scheibel1-1/+1
2020-11-12macos: update build process to use spawn instead of fork (#18205)Peter Scheibel1-1/+4
Spack creates a separate process to do package installation. Different operating systems and Python versions use different methods to create it but up until Python 3.8 both Linux and Mac OS used "fork" (which duplicates process memory, file descriptor table, etc.). Python >= 3.8 on Mac OS prefers creating an entirely new process (referred to as the "spawn" start method) because "fork" was found to cause issues (in other words "spawn" is the default start method used by multiprocessing.Process). Spack was dependent on the particular behavior of fork to replicate process memory and transmit file descriptors. This PR refactors the Spack internals to support starting a child process with the "spawn" method. To achieve this, it makes the following changes: - ensure that the package repository and other global state are transmitted to the child process - ensure that file descriptors are transmitted to the child process in a way that works with multiprocessing and spawn - make all the state needed for the build process and tests picklable (package, stage, etc.) - move a number of locally-defined functions into global scope so that they can be pickled - rework tests where needed to avoid using local functions This PR also reworks sbang tests to work on macOS, where temporary directories are deeper than the Linux sbang limit. We make the limit platform-dependent (macOS supports 512-character shebangs) See: #14102
2020-10-23csh: don't require SPACK_ROOT for sourcing setup-env.csh (#18225)Todd Gamblin1-1/+1
Don't require SPACK_ROOT for sourcing setup-env.csh and make output more consistent
2020-10-11Add testing for Python 3.9 (#19261)Adam J. Stewart1-1/+1
2020-09-02Mac OS: support Python >= 3.8 by using fork-based multiprocessing (#18124)Rui Xue1-1/+1
As detailed in https://bugs.python.org/issue33725, starting new processes with 'fork' on Mac OS is not guaranteed to work in general. As of Python 3.8 the default process spawning mechanism was changed to avoid this issue. Spack depends on the fork-based method to preserve file descriptors transparently, to preserve global state, and to avoid pickling some objects. An effort is underway to remove dependence on fork-based process spawning (see #18205). In the meantime, this allows Spack to run with Python 3.8 on Mac OS by explicitly choosing to use 'fork'. Co-authored-by: Peter Josef Scheibel <scheibel1@llnl.gov> Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com> Co-authored-by: Todd Gamblin <tgamblin@llnl.gov>
2020-08-01Avoid update and upgrades to brew (#17815)Massimiliano Culpo1-2/+0
Ci is currently failing on brew update with the error: ``` Error: Cannot install bazelisk because conflicting formulae are installed. bazel: because Bazelisk replaces the bazel binary Please `brew unlink bazel` before continuing. Unlinking removes a formula's symlinks from /usr/local. You can link the formula again after the install finishes. You can --force this install, but the build may fail or cause obscure side effects in the resulting software. ``` Avoiding: ``` $ brew update $ brew upgrade ``` solves the issue by preventing the risk of conflicting formulae
2020-07-29Use "fetch-depth: 0" to retrieve all history from remoteMassimiliano Culpo1-1/+3
2020-07-29Simplified YAML files for Github Actions workflowsMassimiliano Culpo1-2/+1
Updated actions where needed
2020-07-29Group tests with similar duration togetherMassimiliano Culpo1-8/+2
Style and documentation tests take just a few minutes to run. Since in Github actions one can't restart a single job but needs to restart an entire workflow, here we group tests with similar duration together.
2020-07-06Remove references to `master` from CITodd Gamblin1-2/+1
- [x] remove master from github actions - [x] remove master from .travis.yml - [x] make `develop` the default branch for `spack ci`
2020-06-30run github workflows on release branches (#17317)Greg Becker1-0/+1
2020-06-15Skip failing test on MacOS (#17072)Massimiliano Culpo1-2/+2
* Skip failing test on MacOS * Update setup-python action and unpin coverage
2020-05-09Fix MacOS tests on developMassimiliano Culpo1-1/+1
The -u option allows to update the current head, so tests won't fail if we are on develop
2020-05-09Add unit test on MacOS using Github Actions (#14220)Massimiliano Culpo1-0/+48
- Remove macos tests from travis - Add macos tests in github actions.