summaryrefslogtreecommitdiff
path: root/.github/workflows
AgeCommit message (Collapse)AuthorFilesLines
2021-05-22Bootstrap clingo from sources (#21446)Massimiliano Culpo1-22/+11
* Allow the bootstrapping of clingo from sources Allow python builds with system python as external for MacOS * Ensure consistent configuration when bootstrapping clingo This commit uses context managers to ensure we can bootstrap clingo using a consistent configuration regardless of the use case being managed. * Github actions: test clingo with bootstrapping from sources * Add command to inspect and clean the bootstrap store Prevent users to set the install tree root to the bootstrap store * clingo: documented how to bootstrap from sources Co-authored-by: Gregory Becker <becker33@llnl.gov> (cherry picked from commit 10e9e142b75c6ca8bc61f688260c002201cc1b22)
2021-05-21Run clingo-cffi tests in a container (#21913)Massimiliano Culpo1-36/+6
There clingo-cffi job has two issues to be solved: 1. It uses the default concretizer 2. It requires a package from https://test.pypi.org/simple/ The former can be fixed by setting the SPACK_TEST_SOLVER environment variable to "clingo". The latter though requires clingo-cffi to be pushed to a more stable package index (since https://test.pypi.org/simple/ is meant as a scratch version of PyPI that can be wiped at any time). For the time being run the tests in a container. Switch back to PyPI whenever a new official version of clingo will be released.
2021-05-21Updates to support clingo-cffi (#20657)Josh Essman1-0/+51
* Support clingo when used with cffi Clingo recently merged in a new Python module option based on cffi. Compatibility with this module requires a few changes to spack - it does not automatically convert strings/ints/etc to Symbol and clingo.Symbol.string throws on failure. manually convert str/int to clingo.Symbol types catch stringify exceptions add job for clingo-cffi to Spack CI switch to potassco-vendored wheel for clingo-cffi CI on_unsat argument when cffi (cherry picked from commit 93ed1a410c4a202eab3a68769fd8c0d4ff8b1c8e)
2020-11-18spack test (#15702)Greg Becker2-2/+2
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-17Github actions: add CI for ASP based solverMassimiliano Culpo1-0/+21
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 Gamblin2-5/+10
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. Stewart5-11/+11
2020-10-11Fix failing mpich build tests (#19259)Adam J. Stewart1-1/+1
By default Spack uses the latest (highest version) GCC compiler available, which might change across updates of the Github CI environment. Since a C compiler is always installed and `mpich~fortran` will result in faster build times, avoid building the FORTRAN interface as part of the test.
2020-09-28macOS CI: replace jupyter with jupyterlab (#19029)Adam J. Stewart1-2/+1
2020-09-02Add new RubyPackage build system base class (#18199)Adam J. Stewart1-2/+11
* Add new RubyPackage build system base class * Ruby: add spack external find support * Add build tests for RubyPackage
2020-09-02Mac OS: support Python >= 3.8 by using fork-based multiprocessing (#18124)Rui Xue3-6/+6
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-03MacOS nightly builds: use Python 3.7 in CIMassimiliano Culpo1-0/+12
Nightly builds with MacOS started failing again due to an upgrade of the default virtual environment that now uses Python 3.8 This makes us hit #14102 and every build fails. This commit should be reverted along with the fix to #14102.
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-31Move Python 2.6 unit tests to Github Actions (#17279)Massimiliano Culpo1-2/+15
* Run Python2.6 unit tests on Github Actions * Skip url tests on Python 2.6 to reduce waiting times * Skip foreground background tests on Python 2.6 to reduce waiting times * Removed references to Travis in the documentation * Deleted install_patchelf.sh (can be installed from repo on CentOS 6)
2020-07-29Use "fetch-depth: 0" to retrieve all history from remoteMassimiliano Culpo4-10/+19
2020-07-29Simplified YAML files for Github Actions workflowsMassimiliano Culpo4-18/+7
Updated actions where needed
2020-07-29Group tests with similar duration togetherMassimiliano Culpo4-76/+72
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-20Fix MacOS build tests (#17542)Massimiliano Culpo2-11/+35
* MacOS build tests - Run on PR that modify the YAML file of the workflow - Don't clone Spack, since we are in the Spack repo now * Try to add opengl to configuration to build jupyter * fixup
2020-07-06Remove references to `master` from CITodd Gamblin3-6/+3
- [x] remove master from github actions - [x] remove master from .travis.yml - [x] make `develop` the default branch for `spack ci`
2020-07-01Moved flake8, shell and documentation tests to Github Action (#17328)Massimiliano Culpo1-0/+80
* Move flake8 tests on Github Actions * Move shell test to Github Actions * Moved documentation build to Github Action * Don't run coverage on Python 2.6 Since we get connection errors consistently on Travis when trying to upload coverage results for Python 2.6, avoid computing coverage entirely to speed-up tests.
2020-07-01Use apple-clang for MacOS nightly tests (#17320)Greg Becker1-6/+6
2020-06-30run github workflows on release branches (#17317)Greg Becker4-0/+4
2020-06-23Added unit tests to Github Actions (#16610)Massimiliano Culpo1-0/+61
* Added unit tests to Github Actions * Set user e-mail and name for git tests to succeed * Simplify setup.sh logic * Replicate Travis script on Github Actions * Update flags since '.' is not allowed * Added badge, simplified workflow * Remove pinning of coverage * Remove unit tests run on Github Actions from Travis
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-09macOS nightly: +1hr py-jupyterAxel Huebl1-1/+1
check if failures ares actually a real timeout or an error that just causes a hang.
2020-05-09macOS nightly: two coresAxel Huebl1-0/+1
All GitHub actions provide two cores. Just make sure this does not get oversubscribed with potentially visible additional physical cores.
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.
2020-05-06macOS Package Builds (nightly) (#16345)Axel Huebl2-0/+62
Add nightly builds for popular and commonly used packages on macOS that should improve the onramp user experience if working well.
2020-04-07Don't run linux build tests for doc PRs (#15895)Adam J. Stewart1-0/+2
2020-03-12Minor updates to CI configuration (#15458)Massimiliano Culpo2-1/+2
* Check on Python versions uses action/checkout@v2 * Update the apt cache before installing system packages
2020-02-27Use checkout v2 to avoid issues on retriggeringMassimiliano Culpo1-1/+1
2019-12-31tests: rename checks in github actionsTodd Gamblin2-4/+4
I usually want to look at the Travis CI output, but I currently have to scroll down to see it. This renames checks to be a bit shorter and more consistent with Travis's naming, and also so that actions appear lower than travis and codecov in the list of checks.
2019-12-25Migrate build tests from Travis to Github Actions (#13967)Massimiliano Culpo1-0/+57
This PR moves build smoke tests from TravisCI and migrates them to Github Actions. The result is that build tests are performed in parallel with unit tests and they don't hog additional resources on Travis. The workflow will not run if a PR only changes packages in the built-in repository, but will always run on pushes to develop or master. * Removed build tests from Travis and passed them to Github Actions * Store ~/.ccache in Github Actions cache * Add filters on paths and make sure this workflow don't run * Use paths-ignore and exclude only files in the built-in repo * Added a badge to README.md
2019-12-24tests: check min required python version with vermin (#14289)Massimiliano Culpo1-0/+30
This commit removes the `python_version.py` unit test module and the vendored dependencies `pyqver2.py` and `pyqver3.py`. It substitutes them with an equivalent check done using `vermin` that is run as a separate workflow via Github Actions. This allows us to delete 2 vendored dependencies that are unmaintained and substitutes them with a maintained tool. Also, updates the list of vendored dependencies.