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
Before this commit we used to run the entire unit test suite
in the presence of a failure. Since we currently rely a lot
on the state of the filesystem etc. the end report was most
of the time showing spurious failures that were a consequence
of the first failing test.
This PR makes unit tests exit at the first failing test
Also, pin codecov at v4.5.4 (last one supporting Python 2.6)
* Travis CI: Test Python 3.8
* Fix use of deprecated cgi.escape method
* Fix version comparison
* Fix flake8 F811 change in Python 3.8
* Make flake8 happy
* Use Python 3.8 for all test categories
fixes#13073
Since #3206 was merged bootstrapping environment-modules was using the architecture of the current host or the best match supported by the default compiler. The former case is an issue since shell integration was looking for a spec targeted at the host microarchitecture.
1. Bootstrap an env modules targeted at generic architectures
2. Look for generic targets in shell integration scripts
3. Add a new entry in Travis to test shell integration
- tests use a shell-script harness and test all Spack commands that
require special shell support.
- tests work in bash, zsh, and dash
- run setup-env.sh tests on macos and linux builds.
- we run them on macos and linux
All macos tests are failing because brew cannot install ccache
without updating brew. This ensures that brew update is run
before using brew in test environment.
- Codecov cannot handle as many coverage reports as we are generating
- as a result, our PR coverage pages have been broken for a while, and
it's hard to tell people where to enhance their testing in PR reviews.
- Scale back to only running coverage for 3.7 and 2.7 unit tests
- This is *probably* better. We run the build tests for good measure,
but we do not need to evaluate them for coverage. The coverage reports
are about unit tests.
* Added the `spack buildcache preview` sub-command
This is similar to `spack spec -I` but highlights which nodes in a DAG
are relocatable and which are not.
spec.tree has been generalized a little to accept a status function,
instead of always showing the install status
The current implementation works only for ELF, and needs to be
generalized to other platforms.
* Added a test to check if an executable is relocatable or not
This test requires a few commands to be present in the environment.
Currently it will run only under python 3.7 (which uses Xenial instead
of Trusty).
* Added tests for the 'buildcache preview' command.
* Fixed codebase after rebase
* Fixed the list of apt addons for Python 3.7 in travis.yaml
* Only check ELF executables and shared libraries. Skip checking virtual or external packages. (#229)
* Fixed flake8 issues
* Add handling for macOS mach binaries (#231)
* Store ccache directory explicitly in Travis.
Despite we started using ccache on `develop`, it seems the cache itself
is not stored from one CI build to the next. This might be du to the
fact that our language on Travis is Python and not C nor C++.
Hence here we store the ccache directory explicitly.
* Unite Dockerfiles - add build/run/push scripts
* update docker documentation
* update .travis.yml
* switch to using a preprocessor on Dockerfiles
* skip building docker images on pull requests
* update files with copyright info
* tweak when travis builds for docker files are done
- Many container builds are timing out frequently during Spack tests in
Travis CI.
- Travis recommends to try `sudo: required` to see whether this is an
infrastructure issue or something else.
- added `sudo: required` to all Linux builds.
- added --verbose to `spack test` invocation so that we can see more
easily what tests it's timing out on.
Signed-off-by: Todd Gamblin <tgamblin@llnl.gov>
- Support for Python 3.3 isn't really needed, as nothing uses it as the
default system Python, and nearly everyone will have a newer Python 3
version installed.
#8223 replaced regex-based makefile target parsing with an invocation of
"make -q". #8818 discovered that "make -q" can result in an error for some
packages.
Also, the "make -q" strategy relied on interpreting the error code, which only
worked for GNU Make and not BSD Make (which was deemed acceptable at
the time). As an added bonus, this implementation ignores the exit code and
instead parses STDERR for any indications that the target does not exist; this
works for both GNU Make and BSD Make.
#8223 also updated ninja target detection to use "ninja -t targets". This does
not change that behavior but makes it more-explicit with "ninja -t targets all"
This also adds tests for detection of "make" and "ninja" targets.
* Test Spack on Python 3.7 as part of Travis CI
* Currently using xenial to pull-in python 3.7
* As xenial is not officially supported yet, Travis tolerates failures on it.
- Frequently, the documentation build will fail mysteriously in some
spack command.
- The cause is some new bug introduced by the PR, but this is not
apparent because the unit tests haven't run and the doc tests aren't
targeted at code bugs.
- Users end up puzzled by doc failures when they're really code failures.
- Move the doc tests parallel with the code tests, so that we can more
easily see bugs like this.
Enforce PEP8 naming conventions for things like variables, methods,
classes, etc.
See the table here:
https://pypi.org/project/pep8-naming/
...for error codes emitted, in case some should be added as
exceptions in the flake8 configuration files.
I think the main issue here is that we ship a custom version of a system
library (`argparse`), and this is prone to fail if `argparse` is
imported before we hack `sys.path` internally.
Probably a better solution would be not to customize argparse, but
instead have a wrapper on top of whatever the system provides.
According to Travis docs the exit code of after_success doesn't affect
the build result. Instead, uploading the coverage data as the last step
of the script will cause the job to fail if the command exits with
non-zero.
https://docs.travis-ci.com/user/customizing-the-build/#Breaking-the-Build
- This should speed-up Travis CI tests and refers to #5049
- Travis uses build-stages to group tests together
- The idea is to let fast tests fail first, then move to longer ones.
- Added external perl to avoid download failure from CPAN and reduce build time
- Disabling perl-dbi: continues to fail with (504 Gateway Time-out) on Travis
- We now cover all the build systems in tests:
- Add back `openblas` to Travis as a separate package.
- Switched `openblas` for `astyle` to build a simpler MakefilePackage.
- Added 'tut' (WafPackage)
- Added 'py-setuptools' (PythonPackage)
- Added 'perl-dbi' (PerlPackage)
- Added 'build_systems' directory to the ones for which we get a summary
- Added 'openjpeg' (CMakePackage)
- Added 'r-rcpp' (RPackage)
- Added comments to build tests to show the covered build system
- Add a `spack gpg` subcommand in anticipation of signed binaries.
- GPG keys are stored in var/spack/gpg, and the spack gpg command manages them.
- Docs are included on the command.
