greenelab / continuous_analysis Goto Github PK

Computational reproducibility using Continuous Integration to produce verifiable end-to-end runs of scientific analysis.

Home Page: https://greenelab.github.io/continuous_analysis/

License: BSD 3-Clause "New" or "Revised" License

Python 0.11% Jupyter Notebook 99.76% Dockerfile 0.13%

supplement continuous-integration reproducibility methodology open-science

continuous_analysis's Introduction

Continuous Analysis

This repository presents Continuous Analysis, a process demonstrating computational reproducibility by producing verifiable end-to-end runs of computational research. The process is described in detail in: Nature Biotechnology and Biorxiv Preprint.

We encourage additions and improvements, please create an issue or better yet, implement it and create a pull request. Please let us know if you run into any difficulty implementing continuous analysis on your own.

Examples

Examples and real applications of continuous analysis are available:

RNA-seq Analysis:
- Using Salmon (and Drone v0.5)
- Using Kallisto
Phylogenetic Tree Building
Microarray Differential Expression Analysis - example from Continuous Analysis Paper
EHR Imputation
Privacy-preserving generative deep neural networks support clinical data sharing
Denoising Autoencoders for Phenotype Stratification

This repository shows example configurations with a locally hosted Drone installation as well as Shippable, wercker and Travis CI. It uses a small test run of Kallisto as an example. The figures below are re-generated with each commit.

Configuration

Configuration instructions can be found here.

Feedback

Please feel free to email me - (brettbe) at med.upenn.edu with any feedback or raise a github issue with any comments or questions. We also encourage you to send examples of your own usage of continuous analysis to be included in the examples section.

Acknowledgements

This work is supported by the Gordon and Betty Moore Foundation's Data-Driven Discovery Initiative through Grant GBMF4552 to C.S.G. as well as NIH grants AI116794 and LM010098 and the Commonwealth Universal Research Enhancement (CURE) Program grant from the Pennsylvania Department of Health to Jason Moore.

continuous_analysis's People

Contributors

Stargazers

Watchers

Forkers

alexwhan combine-lab rob-p dhimmel resurgo-genetics neksa qiangzhongwork julianpistorius akhileshkaushal inambioinfo naveen584 keshava deepstatsanalysis

continuous_analysis's Issues

FYI your nature biotech link in the readme is broken

Develop branch behind master

the develop branch states:

This branch is 16 commits behind master.

Is develop in use? Why is it behind master? Where should I submit pull requests?

Add a description and website to GitHub

Currently, the GitHub repository states:

No description or website provided.

This issue also pertains to another public Greene Lab repo: https://github.com/greenelab/continuous_analysis_phylo

Multi-container continous analysis using Docker compose

As @brettbj and I have discussed, I'm skeptical that complex computational environments should always be coerced into a single docker image. Instead you may have multiple images that extend different parent images. For example, I may require an extended Neo4j (database) image and an extended Python image.

It looks like Docker Compose is the solution:

Compose is a tool for defining and running multi-container Docker applications. With Compose, you use a Compose file to configure your application’s services. Then, using a single command, you create and start all the services from your configuration.

Discovered Compose through @awm33 who implemented it in one of our Project Cognoma repositories: cognoma/core-service#34. Just wanted to post this as something to keep in mind going forward.

Use GitHub deploy keys rather than personal access tokens

Currently, it looks like $git_publish_key is a GitHub personal access token. This gives the CI service full access to a user's account. For improved security, it would be ideal to limit the CI service's write access to the specific repository being continuously analyzed.

Deploy keys offer this functionality:

A deploy key is an SSH key that is stored on your server and grants access to a single GitHub repository. This key is attached directly to the repository instead of to a personal user account.

As an example, see dhimmel/thinklytics@39e2ae0, where I switched from a personal access token to a deploy key.

Does Kallisto's proprietary license create Docker incompatibility?

This repo builds a Docker image that includes Kallisto, which has a proprietary license that states:

Permission to use, copy, modify, and distribute this software and its documentation for educational and research not-for-profit purposes, without fee and without a signed licensing agreement, is hereby granted

There are two potential issues with Kallisto's license:

Is the distribution of the Docker image (brettbj/continuous_analysis_base) commercial? If so, Kallisto's license would be violated. However, I think this is unlikely as no one is profiting from distributing this image.
Does creating an image with Kallisto violate linux's GPL licensing. Since Kallisto's license discriminates against commercial use, it's not open source software. According to GNU FAQs, the answer is nuanced:

However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.

The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing.

If the two programs remain well separated, like the compiler and the kernel, or like an editor and a shell, then you can treat them as two separate programs—but you have to do it properly. The issue is simply one of form: how you describe what you are doing. Why do we care about this? Because we want to make sure the users clearly understand the free status of the GPL-covered software in the collection.

So if the Docker image makes Kallisto inseparable from Linux, then there may be licensing incompatibility. I personally think that the Docker image may keep Linux and Kallisto as "two separate programs."

Of course, this is not legal advice and I'm not a lawyer. I'm opening this issue as a place for us to collect our thoughts on the issue. At this point, I'm not suggesting that you remove Kallisto.

For more information, here's a discussion of licensing issues in the Docker era.