Github repository: https://github.com/JCSDA/spack-stack

Documentation: https://spack-stack.readthedocs.io/en/latest/

Third party dependencies: licenses

https://docs.google.com/spreadsheets/d/1k3aMu8gkEsAZGJRUqYTx1iQG4xFnJGqe/edit#gid=220490890

spack-stack Development

If you are going to contribute to the spack-stack repository, development is done by forking the spack-stack repository. This section contains steps to fork spack-stack from https://github.com/JCSDA/spack-stack, make changes, and issue a PR. 

1. Create a fork of https://github.com/JCSDA/spack-stack by clicking the "Fork" button on the top right side of the page to "Fork your own copy of JCSDA/spack-stack". 
2. Navigate to your repositories and click on the spack-stack repo. Clicking the green "Code" button will show you options to clone this repository. One option is by using https and running git clone https://github.com/<your_username>/spack-stack.git 
3. Rename your fork to your name in order to help keep track of multiple user and the authoritative forks. Therefore after you clone the repository run git remote rename origin <your_name> . This can be verified by running git remote -v 
4. You can now create a branch and start developing. Note, make sure you pull the authoritative develop brand if your fork is out of date. 
5. Once your branch is ready for review, you will need to create a PR inside https://github.com/JCSDA/spack-stack pointing to your fork and branch. Push your PR to your fork by running git push <your_name> feature/<your_branch> . Then open the PR request form in a bowser adding the necessary information and setting the base repository to JCSDA/spack-stack.

For further reading on using github forks, checkout this site and this one too.

spack-stack Testing

JCSDA is currently responsible for testing spack-stack environments on S4 and Discover. The documented instructions for building spack-stack on HPC platforms are very good but there are two things to take care of before starting (as noted in the instructions).

1. Make sure you are pointing to a python that is version 3.8 or higher

   HPC Platform	python3.8+ environment
   S4	module load miniconda/3.8-s4
   Discover	module load python/GEOSpyD/Min4.10.3_py3.9

2. Make sure you have checked out the branches you need to test before running the setup.sh script

   1. Typically you will be testing feature branches that could have come from various developers. Each of these developers has their own fork of which will be marked on the PR, and you will need to check those out in your local clone. One way to do this is to add their forks to your remotes in your local clone. This can be done using a series of the "git remote add ..."  command. Here's an example:

      Add remote repos to your local clone

      # Alex Richert (NOAA) and Dom (NRL) are two of the more active PR contributors
      git remote add alex	https://github.com/AlexanderRichert-NOAA/spack-stack 
      git remote add dom	https://github.com/climbfuji/spack-stack
      ...
      
      # Check that you have these entered
      git remote -v
      
      # Update references to the other forks. Running the remote update
      # command below will pull in all the metadata to the other forks.
      git remote update -p
      
      # Check that you got the references to the other forks (note the use of
      # the -a option on the git branch command)
      git branch -avv

   2. Once you have the necessary remotes added, then you can checkout feature branches from other repos

      Check out feature branches from other forks

      # Using the remote link entered above, checkout the feature/cool-spack-thing from Dom's spack-stack fork
      git checkout dom/feature/cool-spack-thing

Once the above steps are done, follow the documented instructions here: building spack-stack on HPC platforms. The ideal goal with the testing is to successfully complete the following steps:

1. Build spack-stack, for each compiler on S4 (intel) and Discover (intel, gnu) both SCU16 and SCU17
2. Using the environment from step 1, build jedi-bundle
3. Set up and try some skylab experiments

Typically, getting all of these steps done is way too much work. I would settle for one of S4 or Discover SCU16 or Discover SCU17, with just one compiler. All of these possibilities are listed for your awareness with the idea that you can round robin between then when testing different feature branches.

Another way to trim down work, is to just verify the spack-stack build, and occasionally carry on through with the jedi-bundle and skylab testing.

Note that you don't need jedipara access to do this testing. You can build everything in your user area on S4 or Discover. To help manage that, both HPC platforms supply commands to show how much of your quota (disk space and number of files) is free. 

Pages

• Setting up CI (spack-stack)