[REVIEW]: Containershare: Open Source Registry to build, test, deploy with CircleCI

[whedon]

Submitting author: @vsoch (Vanessa Sochat)
Repository: https://www.github.com/vsoch/containershare
Version: 0.0.3
Editor: @arfon
Reviewer: @brainstorm
Archive: 10.5281/zenodo.1341099

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/a81c73bbacc0345302f77bbdf2597dc1"><img src="http://joss.theoj.org/papers/a81c73bbacc0345302f77bbdf2597dc1/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/a81c73bbacc0345302f77bbdf2597dc1/status.svg)](http://joss.theoj.org/papers/a81c73bbacc0345302f77bbdf2597dc1)

Reviewers and authors:

Please avoid lengthy details of difficulties in the review thread. Instead, please create a new issue in the target repository and link to those issues (especially acceptance-blockers) in the review thread below. (For completists: if the target issue tracker is also on GitHub, linking the review thread in the issue or vice versa will create corresponding breadcrumb trails in the link target.)

Reviewer instructions & questions

@brainstorm, please carry out your review in this issue by updating the checklist below. If you cannot edit the checklist please:

1. Make sure you're logged in to your GitHub account
2. Be sure to accept the invite at this URL: https://github.com/openjournals/joss-reviews/invitations

The reviewer guidelines are available here: https://joss.theoj.org/about#reviewer_guidelines. Any questions/concerns please let @arfon know.

✨ Please try and complete your review in the next two weeks ✨

Review checklist for @brainstorm

Conflict of interest

• As the reviewer I confirm that I have read the JOSS conflict of interest policy and that there are no conflicts of interest for me to review this work.

Code of Conduct

• I confirm that I read and will adhere to the JOSS code of conduct.

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v.0.0.1)?
• Authorship: Has the submitting author (@vsoch) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
• Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
• Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
• Automated tests: Are there automated tests or manual steps described so that the function of the software can be verified?
• Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Software paper

• Authors: Does the paper.md file include a list of authors with their affiliations?
• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• References: Do all archival references that should have a DOI list one (e.g., papers, datasets, software)?

[whedon]

Hello human, I'm @whedon. I'm here to help you with some common editorial tasks. @brainstorm it looks like you're currently assigned as the reviewer for this paper 🎉.

⭐ Important ⭐

If you haven't already, you should seriously consider unsubscribing from GitHub notifications for this (https://github.com/openjournals/joss-reviews) repository. As a reviewer, you're probably currently watching this repository which means for GitHub's default behaviour you will receive notifications (emails) for all reviews 😿

To fix this do the following two things:

1. Set yourself as 'Not watching' https://github.com/openjournals/joss-reviews:

2. You may also like to change your default settings for this watching repositories in your GitHub profile here: https://github.com/settings/notifications

For a list of things I can do to help you, just type:

@whedon commands

[whedon]

Attempting PDF compilation. Reticulating splines etc...

[whedon]

--> Check article proof 📄 <--

[brainstorm]

Alright, let's start! Thanks @arfon 👍

@vsoch Your project/repo seems quite well put together, but I have one question you'll have to motivate a bit more on paper.md: How does containershare compare/supersede/complement/replace/deprecate http://biocontainers.pro/ (https://github.com/BioContainers/containers) and other similar initiatives in this space from i.e ELIXIR-like initiatives in this space?

In other words, paper.bib needs a bit more refs to motivate the "Statement of need", IMHO ;)

[brainstorm]

@vsoch: Minor wrinkle: I would adhere to semver better by dropping the initial v in your releases, i.e 0.0.1 instead of v0.0.1.

[brainstorm]

Could you also have a small mention on how to run the unit tests? ;)

[vsoch]

Thanks for the speedy update @brainstorm and @arfon (and @whedon!) I've done the following changes to address the review comments:

• a first shot at explaining the difference between containershare and biocontainers. I'm not terribly familiar with biocontainers, but it seems to serve as a general listing of bioinformatics containers, and isn't intended to be a general template to extend to other purposes and provide extended metadata (beyond an image manifest). It doesn't take a distributed strategy of requiring each container repository to serve not only different kinds of metadata, but also a LICENSE and README, and it seems to be less lightweight in requiring a registry server for the API. Containershare serves it's api from Github pages without additional dependencies. To summarize, I'd say containershare is a more lightweight, customizable solution that is picker about its containers spilling their tiny souls for inspection.
• The tag will be changed to remove the v on the next tagged release (after our changes and discussion!) to adhere to semvar.
• I had not provided clear steps for running tests locally, and actually since on CircleCI the tests are only run for newly added files, I had missed a test not passing (the julia-share was missing a license!). I've updated both the containershare testing software (version to 0.0.14), the missing license along with adding instructions to the README to test locally. I'm really glad you asked about this!

I think that should be good for this first tweak - take a look and let me know what needs more work! I'll also note that I have several new container templates in the queue - the exciting thing about this work is that it isn't a static "it's done now and forever" thing, it's going to be extended to have lots of different container types (templates) that a user can add to the containershare!

[vsoch]

I just edited @whedon 's version up to what we will tag as the final release, after review:

**Version:** 0.0.3

I didn't realize I could do that :)

[vsoch]

heyo everyone! For a full circle test of the above changes, I added a repo2docker-julia template just now, and everything worked as I would want and expect! You can see:

• the CircleCI testing here
• the pull request here

And upon merge, the table and associated linked metadata was updated.

[brainstorm]

Cool, thanks for the quick changes @vsoch, all LGTM now.

I would suggest to add a bib reference to biocontainers since you mention them... not sure they even have a preprint though, care to contact and ask them?: http://biocontainers.pro/#contact

Other than that, all clear, good job! ;)

[vsoch]

oh hmm, I definitely did that! I think Mr.Whedon just needs to rebuild the pdf? Let me see if I can figure that out... @whedon commands

[vsoch]

@whedon commands

[whedon]

Here are some things you can ask me to do:

# List Whedon's capabilities
@whedon commands

# List of editor GitHub usernames
@whedon list editors

# List of reviewers together with programming language preferences and domain expertise
@whedon list reviewers

🚧 🚧 🚧 Experimental Whedon features 🚧 🚧 🚧

# Compile the paper
@whedon generate pdf

[vsoch]

@whedon generate pdf

[whedon]

Attempting PDF compilation. Reticulating splines etc...

[whedon]

--> Check article proof 📄 <--

[vsoch]

See it now? Thanks @whedon ! You da bomb' bot.

[brainstorm]

Haha, great then, all clear from my side, @arfon, over to you ;)

[vsoch]

Thanks @brainstorm! You da bomb'man. :)

[arfon]

@vsoch - At this point could you make an archive of the reviewed software in Zenodo/figshare/other service and update this thread with the DOI of the archive? I can then move forward with accepting the submission.

[vsoch]

All set! version 0.0.3 with the final work is here --> https://zenodo.org/account/settings/github/repository/vsoch/containershare# pointing to https://github.com/vsoch/containershare/releases/tag/0.0.3.

The link for the doi provided is https://zenodo.org/badge/latestdoi/142066803 (although not found yet?)

Let me know if you need anything else!

[arfon]

@whedon set 10.5281/zenodo.1341099 as archive

[whedon]

OK. 10.5281/zenodo.1341099 is the archive.

[arfon]

@brainstorm - many thanks for your review here ✨

@vsoch - your paper is now accepted into JOSS and your DOI is https://doi.org/10.21105/joss.00878 ⚡ 🚀 💥

[whedon]

🎉🎉🎉 Congratulations on your paper acceptance! 🎉🎉🎉

If you would like to include a link to your paper from your README use the following code snippets:

Markdown:
[![DOI](http://joss.theoj.org/papers/10.21105/joss.00878/status.svg)](https://doi.org/10.21105/joss.00878)

HTML:
<a style="border-width:0" href="https://doi.org/10.21105/joss.00878">
  <img src="http://joss.theoj.org/papers/10.21105/joss.00878/status.svg" alt="DOI badge" >
</a>

This is how it will look in your documentation:

We need your help!

Journal of Open Source Software is a community-run journal and relies upon volunteer effort. If you'd like to support us please consider doing either one (or both) of the the following:

• Volunteering to review for us sometime in the future. You can add your name to the reviewer list here: http://joss.theoj.org/reviewer-signup.html
• Making a small donation to support our running costs here: https://www.flipcause.com/secure/cause_pdetails/Mjk3Nzk=

[vsoch]

Woohoo! So awesome! Thank you @brainstorm @arfon, and of course, the fearless @whedon :)