These versions can cause weird concretizations, and it looks like the
old version of xsdk may not even work because of xsdktrilinos being
disabled. The hypre version tagged for xsdk@0.2 no longer exists at the
described location.
With the previous naming scheme, `trilinos@:10` concretizes to
`trilinos@xsdk-0.2.0`. Now, it's clear what the xsdk version is closest
to. Changed from tag to the corresponding commit SHA for safety.
* Do not allow cray build system patch for later version of otf2
* Modify flag_handler logic in the trilinos package
Modify flag_handler logic in the trilinos package to work better with compilers
other than CCE
Run CTest at build time with:
```
spack install --test=root openpmd-api@<version>
```
and run smoke-tests after install and loading of the package via
```
spack load -r /<spec>
spack test run /<spec>
```
This pull request adds a new workflow to build and deploy Spack Docker containers
from GitHub Actions. In comparison with our current system where we use Dockerhub's
CI to build our Docker containers, this workflow will allow us to now build for multiple
architectures and deploy to multiple registries. (At the moment x86_64 and Arm64 because
ppc64le is throwing an error within archspec.)
As currently set up, the PR will build all of the current containers (minus Centos6 because
those yum repositories are no longer available?) as both x86_64 and Arm64 variants. The
workflow is currently setup to build and deploy containers nightly from develop as well as
on tagged releases. The workflow will also build, but NOT deploy containers on a pull request
for the purposes of testing this PR. At the moment it is setup to deploy the built containers to
GitHub's Container Registry although, support for also uploading to Dockerhub/Quay can be
included easily if we decide to keep releasing on Dockerhub/want to begin releasing on Quay.
This is an attempt to fix "Missing base commit" messages in the codecov UI. Because we do not run
full tests on package PRs, package PRs' merge commits on `develop` don't have coverage info. It
appears that codecov will give you an error if the pseudo-base's coverage data doesn't all apply
properly to the real PR base, unless the `allow_coverage_offsets` option is set.
* See here for docs:
https://docs.codecov.com/docs/comparing-commits#pseudo-comparison
* See here for another potential solution:
https://community.codecov.com/t/2480/15
`compare_specs()` had a `colorful` keyword argument, but everything else in
spack uses `color` for this.
- [x] rename the argument
- [x] make the default follow spack's `--color=always/never/auto` setting
* Bump py-boto3, add python constraints, bump deps
* Update var/spack/repos/builtin/packages/py-boto3/package.py
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
* Update var/spack/repos/builtin/packages/py-boto3/package.py
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
* Update var/spack/repos/builtin/packages/py-boto3/package.py
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
* Add py-os-service-types
* Update var/spack/repos/builtin/packages/py-os-service-types/package.py
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
* Add py-oslo-i18n
* Update var/spack/repos/builtin/packages/py-oslo-i18n/package.py
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
* Bump py-botocore and add python constraints
* Update var/spack/repos/builtin/packages/py-botocore/package.py
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
