* Fix CD: Packages Service First
Build the packages.spack.io service images first, so they are
guaranteed to be pushed even if further images fail to build.
Fix the query to the `spack` script executed in later builds.
* CD: Remove Spack Images
Now done on Dockerhub.
- We don't currently make enough use of the maintainers field on
packages, though we could use it to assign reviews.
- add a command that allows maintainers to be queried
- can ask who is maintaining a package or packages
- can ask what packages users are maintaining
- can list all maintained or unmaintained packages
- add tests for the command
* fix docker builds/remove extra builds/add ci builds
* preinstall vim in CI builder images
* simplify & streamline docker resources
* restore os-container-mapping.yaml file
- [x] Add shell tests to ensure that `spack env activate`, `spack env
deactivate`, and `despacktivate` continue to work.
- [x] Also ensure that activate and deactivate both work with `set -u`
* Add template creation test
* Added --skip-editor option to "spack create": normally
"spack create" opens an editor for the user after generating a
package file; when the --skip-editor option is used, "spack create"
only generates the package file and does not open an editor
* Added --skip-editor option to bash completion
- `setup-env.sh` was not properly detecting a bash shell when bash was run
as /bin/sh.
- Detection routine now always reports bash when bash is run as sh, and
no longer parses the path to the executable indicated in `$BASH`.
- Add set -u to the setup-env.sh test script
- Refactor lines in setup-env.sh that tested potentially undefined
variables to use the `[ -z ${var+x} ]` construct
- 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
- replace use of [[ with [
- replace function foo { .. } with foo() { .. }
- wrap some long lines
- add lsof and /proc/fd magic so that we can find the sourced file even in dash
- only do the complicated shell checks in one place; test $_sp_shell
elsewhere.
- We've seen this a few times now where users have set up `cd` to echo
the new directory, and it screws up `setup-env.sh`
- In the past we've said this is user error.
- Here, we just fix it by sending `cd` output to /dev/null where needed.
- this works in bash, zsh, and dash
- 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 a function that concretizes specs together
* Specs concretized together are copied instead of being referenced
This makes the specs different objects and removes any reference to the
fake root package that is needed currently for concretization.
* Factored creating a repository for concretization into its own function
* Added a test on overlapping dependencies
Usage of double quotes was preventing word-splitting when parsing
module roots in setup-env.sh, which lead to an error when multiple
module roots are used (in particular when Spack is pointed to use
an upstream module root in addition to its own).
Still look for BASH_SOURCE[0] first, but if it's not set,
_sp_source_file is initialized to an empty value addressing the
unset parameter error (line 217).
* initial work to make use of an 'upstream' spack installation: this uses the DB of the upstream installation to check if a package is installed
* need to query upstream dbs when adding new record to local db
* prevent reindexing upstream DBs
* set prefix on specs read from DB based on path stored in install record
* check that Spack does not install packages that are recorded as installed in an upstream db
* externals do not add their path to install records - need to use 'external_path' to get path of upstream externals
* views need to check for upstream installations when linking metadata
* package and spec now calculate upstream installation properties on-demand themselves rather than depending on concretization to set these properties up-front. The added tests for upstream installations don't work with this new strategy so they need to be updated
* only refresh modules for local specs (not those in upstream packages); optionally generate local module files for packages installed upstream
* when a user tries to locate a module file for a package installed upstream, tell them to use the upstream spack instance to locate it
* support recursive upstream databases (allow upstream databases to use their own upstream databases)
* separate upstream config into separate file with its own schema; each entry now also includes a name
* metadata_dir is no longer customizable on a per-instance basis for YamlDirectoryLayout
* treat metadata_dir as an instance variable but dont set it from kwargs; this follows several other hardcoded variables which must be consistent between upstream and downstream DBs. Also update DirectoryLayout.metadata_path to work entirely with Spec.prefix, since Spec.prefix is set from the DB when available (so metadata_path was duplicating that logic)
This spack command adds a new schema for a file which describes the
builder containers available, along with the compilers availabe on
each builder. The release-jobs command then generates the .gitlab-ci.yml
file by first expanding the release spec set, concretizing each spec
(in an appropriate docker container if --this-machine-only argument is
not provided on command line), and then combining and staging all the
concrete specs as jobs to be run by gitlab.
The built images are set up with fairly recent versions of gcc and
clang:
- centos_7: [ gcc@5.5.0 (built from src), clang@6.0.0 (spack-built from src) ]
- ubuntu_18.04: [ gcc@5.5.0 (system), clang@6.0.0-1ubuntu2 (system) ]
Adds four new sub-commands to the buildcache command:
1. save-yaml: Takes a root spec and a list of dependent spec names,
along with a directory in which to save yaml files, and writes out
the full spec.yaml for each of the dependent specs. This only needs
to concretize the root spec once, then indexes it with the names of
the dependent specs.
2. check: Checks a spec (via either an abstract spec or via a full
spec.yaml) against remote mirror to see if it needs to be rebuilt.
Comparies full_hash stored on remote mirror with full_hash computed
locally to determine whether spec needs to be rebuilt. Can also
generate list of specs to check against remote mirror by expanding
the set of release specs expressed in etc/spack/defaults/release.yaml.
3. get-buildcache-name: Makes it possible to attempt to read directly
the spec.yaml file on a remote or local mirror by providing the path
where the file should live based on concretizing the spec.
4. download: Downloads all buildcache files associated with a spec
on a remote mirror, including any .spack, .spec, and .cdashid files
that might exist. Puts the files into the local path provided on
the command line, and organizes them in the same hierarchy found on
the remote mirror
This commit also refactors lib/spack/spack/util/web.py to expose
functionality allowing other modules to read data from a url.
Spack shell detection in setup-env.sh was originally based on
examining the executable name of $$ (from "ps"). In some cases this
does not actually give the name of the shell used, for example when
setup-env.sh was invoked from a script using "#!". To make shell
detection more robust, this adds a preliminary check for shell
variables which indicate that the shell is bash or zsh; the
executable name of $$ is retained as a fallback if those variables
are not defined.
- currently just looks at patches
- allows you to find out which package applied a patch to a spec
- intended to work with tarballs and resources in the future.
- add tab completion for `spack resource` and subcommands
