tweaks to README to add testing instructions

.circleci/config.yml

@@ -26,7 +26,7 @@ jobs:
           command: |
             wget https://repo.continuum.io/miniconda/Miniconda3-latest-Linux-x86_64.sh
             /bin/bash Miniconda3-latest-Linux-x86_64.sh -b 
-            $HOME/miniconda3/bin/python -m pip install pyaml containershare==0.0.12
+            $HOME/miniconda3/bin/python -m pip install pyaml containershare==0.0.14
             cd $HOME/containershare/docs
             $HOME/miniconda3/bin/python ../tests/circle_urls.py $HOME/containershare/docs/_site
       - run:

README.md

@@ -50,3 +50,60 @@ When the pull request is merged, the container will be added to [the table](http
 
 ## Deploy a Registry
 If you want to deploy your own containershare, it's just a matter of forking this repository, and turning on Github pages to deploy from the docs folder, and then connecting the repository to circleci. Once this is done, third parties (others) should be able to equivalently submit pull requests to your registry that are tested, and upon merge, the container contribution added to the table, and the container available for discovery via the API exposed by the registry.
+
+### Local Tests
+The testing step of the registry that occurs on CircleCI is optimized to only test newly added files (so previous additions do not need to be tested and take, however the testing can be run locally (and manually) if desired. The general steps would be to do the following:
+
+ - build the site locally with jekyll
+ - inspect the image manifest
+ - for each new container represented as a markdown file in the library, check that it serves metadata
+
+#### Step 1. Build the Jekyll Site
+You can [install jekyll](https://jekyllrb.com/docs/installation/) for your platform of interest], and build the site after
+cloning the repository:
+
+```bash
+git clone https://www.github.com/vsoch/containershare
+cd containershare/docs
+jekyll build
+```
+
+This will generate static content for the site (including the library.json API file) in the `_site` folder.
+Check it out!
+
+```bash
+cat _site/library.json
+```
+
+#### Step 2. Install Containershare
+Containershare has a small [python library](https://pypi.org/project/containershare/) that is used to run the tests,
+and this is done to ensure versioning of the testing itself. You can install this library (check the `.circleci/config.yml`
+for the updated version, at the time of this writing the current version is 0.0.14) and then use it to run tests on the static
+generated content.
+
+```bash
+pip install pyaml containershare==0.0.14
+```
+
+It's assumed that you have some flavor of python installed, along with the package manager pip. To
+use the exact version that the CircleCI is using, these are the steps to install:
+
+```bash
+wget https://repo.continuum.io/miniconda/Miniconda3-latest-Linux-x86_64.sh
+/bin/bash Miniconda3-latest-Linux-x86_64.sh -b 
+$HOME/miniconda3/bin/python -m pip install pyaml containershare==0.0.14
+```
+
+#### Step 3. Test the library
+The final command will run the tests! If you are in the "docs" folder, go up one level back
+to the base of the repository ("tests" should be in the present working directory). Note that in the CircleCI
+continuous integration, the tests are run like this:
+
+```bash
+python -m unittest tests.test_library
+```
+
+The above command will run through the library, and for each entry, clone the Github repository
+Github pages and master branches, and check for all metadata files (tags.json, inspections and image manifests) along with "human friendly" metadata like a LICENSE and README. Finally, the tests ensure
+that the Github Pages (or other preview link) is deployed based on a 200 status return, and that
+the name does not include any invalid characters (outside of numbers, letters, `-` `_` and `/`).

paper/paper.md

@@ -24,8 +24,10 @@ Containershare is an open source library of containers, both providing itself as
 
 ![https://vsoch.github.io/assets/images/posts/containershare/table.png](https://vsoch.github.io/assets/images/posts/containershare/table.png)
 
-While several frameworks exist with a primary goal to provide a listing of container builds (e.g., biocontainers [@Da_Veiga_Leprevost2017-xx]) containershare is unique in its requirement for each container to serve more substantial metadata. For example, while biocontainers also takes advantage of services like Docker Hub to provision a build, it doesn't go out of its way to provide any more metadata than a standard image manifest. The manifests themselves and the container listings are not served using a distributed strategy. While biocontainers shines and succeeds to provide a listing of containers, it's prime purpose is to provide a simple listing of bioinformatics containers, and not to empower other users to deploy similar initatives branded for their containers. Whereas the containershare Github repository works as an API, biocontainers does not appear to have any metadata served from the respository directly. Further, containershare takes a distributed strategy of serving metadata from each included repository allowing for individual containers to have unique and distinct tests, if wanted.
-
+While several frameworks exist with a primary goal to provide a listing of container builds (e.g., biocontainers [@Da_Veiga_Leprevost2017-xx]) containershare is unique in its requirement for each container to serve more substantial metadata. For example, while biocontainers also takes advantage of services like Docker Hub to provision a build, it doesn't go out of its way to provide any more metadata than a standard image manifest. Each repository is required to serve a listing of tags, image inspections (files with sizes and package versions) and image manifests via Github pages, and also a LICENSE and README file from the master branch. Further, there is no additional software or server dependency on serving the API, because the entire
+operation happens via Github Pages and continuous integration. The manifests themselves and the container listings are served using a distributed strategy so that the primary containershare repository is not eventually overwhelmed with growing size, and a listing of tags are provided to discover
+container metadata for current and past builds, each associated with a Github commit. While biocontainers shines and succeeds to provide a listing of bioinformatics containers, it seems to require an additional registry backend and setup. In comparison, containershare is a more lightweight solution intended to empower other users to deploy similar initatives branded for their containers. Whereas the containershare Github repository works as an API, biocontainers does not appear to have any metadata served from the respository directly, container versions are not obviously linked to Github commits, and previous tags are not directly
+accessible. Further, containershare takes a distributed strategy of serving metadata from each included repository, allowing for individual containers to have unique and distinct tests, if wanted.
 
 ## Container Repository Templates
 

tests/test_library.py

@@ -59,6 +59,7 @@ class TestSubmission(unittest.TestCase):
     def setUp(self):
         self.tmpdir = tempfile.mkdtemp()
         self.LibValidator = LibraryValidator()
+        self.RuntimeValidator = RuntimeValidator()
 
     def tearDown(self):
         shutil.rmtree(self.tmpdir)