# How to Share a Reproducible R Bioinformatics Workflow

The difference between a script someone can read and a workflow someone can rerun is the execution environment: version-pinned packages, containerized dependencies, and a documented entry point. The rule of thumb for choosing how to share your work is simple. If a single collaborator needs to rerun one [statistical analysis](/blog/guides/statistical-analysis) on their laptop, a version-controlled repository with a locked package environment and a rendered report is enough. If your workflow chains command-line tools, processes large sequencing or spectrometry data, or must run on a high-performance computing (HPC) cluster shared by many institutions, wrap it in a scientific workflow engine with containers so the whole pipeline moves as one unit.

This article walks through every practical option for sharing an R-based bioinformatics workflow, compares them side by side, gives worked scenarios, and lists the mistakes that most often break reproducibility after you hit "share."

## Why Reproducibility Is Hard in R for Bioinformatics

R is one of the dominant languages for statistical analysis in biology, and the Bioconductor project supplies thousands of peer-reviewed packages for genomics, [transcriptomics](/knowledge/bioinformatics/modern-transcriptomics-bulk-single-cell-spatial), proteomics, and metabolomics. That power comes with a reproducibility tax. Bioconductor releases on a fixed schedule, packages depend on specific R versions, and a script that ran cleanly six months ago can fail after a routine package update. Researchers in mass spectrometry have a name for this problem: "workflow decay," the loss of a working analysis pipeline because it depended on a computing platform that was too specific and was never standardized [1].

The problem compounds in real bioinformatics settings. A typical genomics analysis is not one R script. It is a chain of computationally intensive steps, where trimming, alignment, variant calling, or peak detection produce intermediate files that feed later statistical analysis in R [2]. Some of those steps run in R, others run in command-line tools written in C, Python, or Java. H3ABioNet, a pan-African network of 27 research institutions in 17 countries, built shared workflows for variant calling, 16S rDNA analysis, genotyping, and SNP imputation precisely because implementing scalable, portable, reproducible workflows on heterogeneous computing environments is one of the hardest parts of modern genomics [2].

When you share a workflow, you are really sharing five things at once:

1. Code, meaning the R scripts, packages, and any command-line steps.
2. Environment, meaning exact package versions, R version, and system libraries.
3. Data and metadata, or at least instructions for obtaining them.
4. Documentation, meaning what each step does, why parameters were chosen, and how to run it.
5. Execution, meaning the single command or interface a newcomer uses to rerun everything.

A shareable workflow addresses all five. A zipped folder of scripts addresses only the first.

## The Main Options for Sharing an R Bioinformatics Workflow

### Option 1: Plain R Scripts With a README

The lowest-effort option is a folder of `.R` scripts plus a README that lists package versions and run order. This is how most analyses start, and it is genuinely better than nothing because the analysis choices are at least written down.

The weakness is environmental. Nothing pins the R version or package versions, and the reader must manually execute scripts in the right order. A review of bioinformatics pipeline development notes that scripting languages such as R are popular and sufficient for small-scale pipelines intended for a single user, but are not enough on their own for large-scale, shareable, maintainable, reusable pipelines that handle large data volumes on HPC clusters [3]. Use plain scripts only as the inner layer of a more structured share.

### Option 2: Literate Reports With R Markdown or Quarto

Literate programming embeds code, results, and narrative in one document. In R, the knitr engine renders R Markdown or Quarto documents so that figures, tables, and statistics are generated by the same code that is shown to the reader. This approach has a strong track record in bioinformatics. A reproducible research workflow for amplicon-based microbiome studies combined the Bioconductor packages dada2 and phyloseq with knitr so that the full set of processing choices, from error filtering and denoising through to exploratory analysis, was documented and rerunnable in one place [4].

Literate reports solve the documentation problem elegantly. The reader sees every parameter, every filter threshold, and every plotting choice in context, and can modify the analysis directly. What they do not solve is environment pinning. A knitted HTML report proves what you ran on your machine, not what will happen on someone else's. Pair reports with a lockfile (Option 4) or a container (Option 5).

A practical Bioconductor tutorial habit worth adopting: keep one master R Markdown or Quarto document per analysis, render it end to end from a fresh R session, and commit both the source and the rendered output to your repository. If the document will not knit from scratch, it is not shareable yet.

### Option 3: An R Package, Optionally on Bioconductor

Formalizing your workflow as an R package is the strongest native-R option. A package forces you to declare dependencies in the DESCRIPTION file, document functions, and include a vignette, which is a rendered tutorial showing intended use. The Bioconductor ecosystem runs heavily on this pattern. Packages such as dada2 and phyloseq distribute methods as installable, documented, versioned units, and published analyses build on them through vignette-style workflows [4]. The MeTime package for longitudinal metabolomics illustrates the modern form: a central S4 container object stores datasets, metadata, and analysis outputs, analyses are built by piping modular functions, and reproducible reporting is generated automatically as HTML or PDF [5]. TidyMass takes the same philosophy further, providing an ecosystem of R packages for LC-MS metabolomics that share a common design philosophy and data structure, with a modular architecture that users can extend and customize [6].

Package-based sharing has real advantages. Dependency declarations are machine-readable, continuous integration can test installation, and the Bioconductor review process enforces documentation and versioning standards for packages accepted into the project. The costs are also real: package development requires writing roxygen2 documentation, unit tests, and news entries, which is a meaningful time investment for a one-off analysis.

A good middle path is to package the reusable core (data containers, processing functions, QC metrics) and drive a specific analysis from a rendered report that calls the package.

### Option 4: Environment Locking With renv and sessionInfo

Environment locking records the exact package versions used in an analysis so a collaborator can restore them. The renv package creates a project-local library and a lockfile (`renv.lock`) that lists every package and version. The canonical sequence is:

```r
renv::init()
renv::snapshot()
```

A collaborator then runs `renv::restore()` to rebuild the exact library. Alongside this, capture `sessionInfo()` output in every rendered report. The systemPipeR package, an R/Bioconductor environment for building and running end-to-end NGS workflows with automated report generation, demonstrates how version and configuration metadata can be embedded directly in workflow reports [7].

Locking is cheap and should be in every repository you share. Its limits matter, though. renv pins R packages but not the underlying system libraries, compilers, or non-R command-line tools. For a pure R analysis on a standard laptop this is usually fine. The moment your workflow calls BWA, samtools, FastQC, or a vendor converter, you need something stronger.

### Option 5: Containers With Docker and Apptainer

A container image bundles the operating system layer, system libraries, R, packages, and external tools into one immutable artifact. Docker is the standard on personal machines and cloud systems. Apptainer (formerly Singularity) is the standard on HPC systems, where users typically lack permission to run Docker.

The MStargetR workflow for targeted mass spectrometry shows the pattern executed well. It consolidates vendor file conversion, peak integration, and quality-control reporting into a single R-native pipeline, and pins its third-party tools in version-controlled Docker images with Apptainer support for high-performance computing [8]. Containerization removed the lab-level variation that previously undermined cross-laboratory comparison of results [8].

For R users, the practical recipe is to start from a versioned R or Bioconductor base image, install your packages from the renv lockfile inside the image, and add any command-line tools with pinned versions. The container plus the Git repository together become the shareable unit. One caveat applies to bioinformatics data: containers hold code, not gigabytes of raw reads. Reference genomes, index files, and input data stay outside the image and are supplied at run time, so document their sources and checksums.

### Option 6: Scientific Workflow Engines

When an analysis spans many tools and large data, a [workflow management](/knowledge/bioinformatics/snakemake-vs-nextflow-workflow-architectures) system coordinates execution, dependencies, restarts, and parallelization. A review of pipeline development in [computational biology](/knowledge/bioinformatics/vaccinomics-and-the-future-of-personalized-vaccines) concludes that scientific workflow systems are the established route to modular, reproducible, reusable bioinformatics pipelines at scale [3]. Three engines matter most for R users.

**Nextflow.** Nextflow runs pipelines written in a declarative syntax, natively supports containers, and handles resumption from cached completed steps. The tcga-data-nf workflow demonstrates the R integration pattern: a Nextflow pipeline downloads, preprocesses, and analyzes TCGA data to infer regulatory networks in a single command, powered by a standalone R package (NetworkDataCompanion) that handles [data management](/blog/guides/data-management-basics-principles-processes-and-best-practices) and filtering inside the pipeline steps [9]. The lesson is that R code does not have to live inside the Nextflow script. Package your R logic as a package, call it from pipeline processes, and let the engine handle data flow.

**Snakemake.** Snakemake expresses workflows as Python-defined rules with input and output files. The Natrix workflow for [amplicon sequencing](/blog/guides/amplicon-sequencing) data uses Snakemake for reproducible execution and Conda for version control of the external programs, covering everything from quality assessment and read assembly through chimera detection and taxonomic assignment [10]. Snakemake rules are deliberately modular, which supports sharing rules between workflows and extending existing ones [10]. R steps fit naturally as rule-level shell or script invocations.

**systemPipeR.** If you want to stay entirely inside R, systemPipeR is an R/Bioconductor package designed for building and running end-to-end NGS workflows with automated report generation, a uniform workflow interface across NGS applications, and support for running both R and command-line software on local computers and clusters [7]. It occupies a useful niche: workflow-engine behavior with an R-native interface and integrated reporting.

Workflow engines demand the most upfront learning of any option here. They pay that back the moment a pipeline must rerun on new data, a new cluster, or a new collaborator's machine.

### Option 7: Galaxy Wrapping R

Galaxy provides a web interface over tools and pipelines, which makes analyses usable by bench scientists with no command-line experience. The GCAC system for virtual screening built a predictive model pipeline on R statistical packages, including descriptor calculation, feature selection, and model building, and wrapped it in the Galaxy workflow system with literate programming tools to ensure reproducibility [11]. The trade-off is control versus accessibility. Galaxy removes execution friction for end users and enforces recorded parameters, but you take on the work of wrapping and maintaining tools in the Galaxy tool shed, and highly customized R analyses can be awkward to expose as Galaxy tools.

### Option 8: Educational and Community Publishing

A distinct goal is teaching others to run and adapt your workflow. The Metabonaut project, an open educational resource for reproducible untargeted LC-MS/MS metabolomics, builds executable example workflows on the R for Mass Spectrometry and Bioconductor ecosystem, carrying FAIR practice from data all the way to analysis, and explicitly demonstrates cross-language interoperability [12]. This model treats the shared workflow itself as a teaching artifact: every vignette runs from real public archive files, and readers modify and rerun the code rather than reading static text [12]. If your aim is community adoption, publishing a package with executable vignettes, a companion website, and worked public-data examples outperforms a bare repository.

## Side-by-Side Comparison of Sharing Options

| Option | Best for | Setup effort | Environment portability | Scales to HPC | Main weakness |
|--|--|--|--|--|--|
| Scripts plus README | Quick internal sharing | Minimal | None | Manual | Breaks silently under package updates |
| R Markdown or Quarto report | Communicating one analysis with all choices visible | Low | None by itself | Limited | Proves your run, not theirs, without locking |
| R package (Bioconductor style) | Reusable methods and community adoption | High | Declared, not frozen | Via engine integration | Documentation and testing overhead |
| renv lockfile | Pinning R package versions in any repository | Low | R packages only | Partial | Ignores system libraries and non-R tools |
| Docker or Apptainer container | Full environment capture, cross-lab consistency | Medium to high | Complete | Apptainer on HPC | Data and large reference files live outside the image |
| Nextflow or Snakemake | Multi-tool pipelines, big data, HPC and cloud | High | Complete with containers | Excellent | Learning curve, overkill for one statistical analysis |
| systemPipeR | R-centric NGS workflows with reports | Medium to high | With containers | Good (local and cluster) | R-centric scope |
| Galaxy | Making pipelines usable without a command line | High | Tool-level | Server dependent | Wrapping effort, less flexibility for custom R |
| Educational resource with vignettes | Teaching and community reuse | High | With containers | Varies | Sustained maintenance commitment |

## Pros and Cons in the Terms That Decide Real Choices

Reading the table, four criteria actually separate these options in practice.

**Who must rerun it.** If the audience is one collaborator reviewing your differential methylation analysis, a locked repository with a knitted report matches the best-practice pattern in the published methylation sequencing protocol, which embeds the downstream R stage, including beta-value calculation and differential analysis with methylKit, inside a unified reproducible pipeline with explicit reporting of intermediate outputs [13]. If the audience is a consortium running on dozens of different compute environments, containerized workflow engines are the norm, which is exactly the approach adopted for shared African genomics infrastructure [2] and for containerized R-native pipelines in metabolomics [8].

**How much of the workflow is R.** A workflow that is 95 percent R locks down cleanly with renv and knits into a report. A workflow that chains Trim Galore, FastQC, BWA-meth, Picard, and MethylDackel before R ever starts [13] needs an engine and containers, because renv alone cannot pin those tools.

**How often it will change.** Iterative exploratory work favors literate reports and package-based containers of functions. Stable production pipelines favor engines, where changing one sample sheet or parameter file triggers a targeted rerun rather than a full manual redo.

**Who maintains it after you.** Repositories rot. Package releases, versioned containers, and workflow engines with pinned software versions are designed to outlive the original author, which is the core motivation behind version-controlled dependencies in systems like Natrix [10] and behind FAIR-oriented educational resources like Metabonaut [12].

## Worked Scenarios

### Scenario 1: A collaborator must verify your differential methylation analysis

You ran Twist Bioscience enzymatic conversion methylation sequencing, and a coauthor's institution must confirm the differential methylation results before submission. Sharing raw scripts would fail the test of transparency that the published best-practices protocol emphasizes, which is multi-stage quality control checkpoints and explicit reporting of intermediate outputs across [preprocessing](/blog/data-analysis/what-is-data-preprocessing), methylation calling, and downstream statistics [13].

The right share here is a Git repository [14] containing the rendered Quarto report, the renv lockfile, the sample metadata table, and a small config file with the alignment and methylation extraction parameters. The collaborator restores the environment, points the config at their copy of the processed data, and reruns one command. Every QC table in their output is generated by the committed code, so agreement or disagreement is auditable.

### Scenario 2: A multi-institution project on heterogeneous clusters

Your genomics pipeline must run at partner sites with different schedulers, module systems, and library versions. This is the H3ABioNet problem exactly, where workflows had to be portable and reproducible across widely varying national computing environments [2]. Lockfiles will not carry samtools or a reference indexer across those machines.

The right share is a Nextflow or Snakemake pipeline with per-process container images, using Apptainer execution on the clusters. Version-controlled containers pin tool versions [8], and the engine abstracts scheduler differences. Keep all R statistical stages in a companion package called from the pipeline, following the tcga-data-nf model of an engine wrapping a purpose-built R package [9].

### Scenario 3: Teaching a method to the community

You want other laboratories to adopt your untargeted metabolomics processing approach. A bare repository teaches poorly because learners cannot tell which choices are essential and which are adjustable. The Metabonaut model answers this with executable vignettes built on the R for Mass Spectrometry and Bioconductor ecosystem, running from real public mzML archives so learners practice on authentic data and see quality-control inspection, archive reuse, and cross-language interoperability demonstrated in code [12]. Package your method, write vignettes against public data, pin the environment, and host the rendered tutorials online.

### Scenario 4: Longitudinal multi-omics analysis with iterative exploration

Your team studies longitudinal metabolomics and keeps changing models. Rebuilding containers on every tweak is friction. The MeTime design shows the alternative: a central S4 container holding datasets, metadata, and all intermediate outputs, with analyses piped from modular functions so the entire workflow stays transparent, modifiable, and reproducibly reported [5]. Here the share is the package plus its automatically generated reports, with the container architecture preserving provenance as you iterate.

## How to Share Your R Bioinformatics Workflow, Step by Step

This is the minimum complete recipe, combining the layers above.

1. **Put the project under Git from day one.** A practical tutorial on FAIR implementation walks through using the Git version control system with R to track changes, collaborate, disseminate, and archive studies through repositories that maintain a complete audit trail of all relevant documents [14]. Commit data-processing code, reports, and configuration together so the history itself is documentation.

2. **Separate code from configuration from data.** Keep sample sheets and parameter files as plain text inputs. Hard-coded paths and embedded credentials are the most common reasons a shared repository cannot run elsewhere.

3. **Lock the R environment.** Initialize renv, snapshot the lockfile, and record `sessionInfo()` in every rendered report.

4. **Containerize anything renv cannot pin.** Build a Docker image from a versioned R or Bioconductor base, install from the lockfile, and add pinned external tools. Provide an Apptainer path if HPC users will run it [8].

5. **Give the workflow one entry point.** Whether that is `Rscript -e "targets::tar_make()"`, `nextflow run ...`, or a Snakemake rule, a newcomer should never have to guess the run order. Workflow engines exist because implicit run order is where shared pipelines fail [3].

6. **Embed quality control checkpoints.** Published best practices for methylation sequencing stress harmonized parameterization and explicit reporting of intermediate outputs so reproducibility is checkable at each stage, not just at the final figure [13]. Emit QC summaries between major steps and include them in the rendered report.

7. **Write the vignette or README as a runnable tutorial.** Follow the Bioconductor convention of executable documentation, demonstrated across the ecosystem from microbiome workflows [4] to metabolomics education [12].

8. **Archive a snapshot with a persistent identifier.** Tag a release on your hosting platform and deposit the archive so published papers can point at an immutable version, consistent with the FAIR goals of findability, accessibility, interoperability, and reusability that guide modern workflow sharing [12].

9. **Choose a license.** Without an explicit license, others have no legal right to reuse your code, which quietly defeats the purpose of sharing it.

## Common Mistakes and Limitations

![Three-column comparison of a knitted report, an renv lockfile and a container across what they pin, what they miss, and when each is enough.](/article-images/illustrations/share-reproducible-r-workflow-bioinformatics-report-vs-lock-vs-container.webp)

- **Sharing a knitted report as proof of reproducibility.** An HTML report documents your run. Without a lockfile or container, it guarantees nothing about anyone else's run. The report is documentation, the environment is reproducibility.
- **Pinning R packages but not system dependencies.** renv cannot freeze the C libraries behind Bioconductor packages or the versions of external tools. When a workflow mixes R with command-line software, only a container or a Conda-based engine environment covers both, which is why Natrix pairs Snakemake with Conda for program version control [10] and MStargetR pins third-party tools in Docker images [8].
- **Hard-coded absolute paths.** `/home/alice/project/rawdata` does not exist on anyone else's machine. Relative paths set in one configuration file are the fix.
- **Letting intermediate files carry undocumented state.** If step 4 silently depends on a filtered table produced by step 2 with parameters nobody recorded, the workflow is not reproducible even if every script is shared. Report intermediate outputs explicitly, as the methylation best-practices protocol recommends [13].
- **Confusing reproducibility with correctness.** A fully containerized pipeline reruns faithfully and can still be wrong. The microbiome workflow literature documents how a multiplicity of choices and inconsistent documentation at each pipeline stage can produce spurious results, which is the argument for documented, reproducible analysis over ad hoc scripts [4]. Reproducibility makes errors auditable, not absent.
- **Skipping a fresh-session test before sharing.** Run your entire workflow in a clean container or a fresh R library on a machine that is not yours before you publish the repository. Most shared workflows fail their first external run because they depended on something in the author's global environment.
- **Overengineering a small analysis.** A two-script differential expression analysis does not need Nextflow, and wrapping it in an engine adds failure modes. A review of pipeline practice is explicit that scripting languages suffice for small-scale single-user pipelines and that workflow systems earn their cost only at larger scale [3].
- **Assuming containers solve data sharing.** Containers carry code. Large sequencing files, reference genomes, and indices need separate provenance documentation, checksums, and, where possible, deposition in public archives.
- **Ignoring the maintenance burden of a public resource.** Educational and community resources such as Metabonaut represent ongoing commitments to keep vignettes running as the underlying ecosystem evolves [12]. Do not publish a tutorial-grade workflow you do not intend to maintain, or say clearly in the README that it is archived as-is.
- **Underestimating cluster variation.** Scheduler quirks, module conflicts, and filesystem differences across institutions are precisely why shared networks build and test workflows against heterogeneous environments rather than assuming one configuration works everywhere [2].

## Frequently Asked Questions

### What is the simplest way to share an R bioinformatics workflow?

A Git repository containing your scripts or a rendered Quarto report, an renv lockfile, a README with one run command, and a license. This combination pins your R package versions, documents every analytical choice in the report, and gives the reader a single starting point, and it takes under an hour to assemble for a typical analysis.

### Should I share my workflow as a Docker container or a Conda environment?

Choose a container when you need complete environment capture, including system libraries and non-R command-line tools, and when collaborators work on laptops or cloud systems. Choose Conda-based environments, typically paired with Snakemake, when your workflow is dominated by external bioinformatics tools and your team wants lightweight, editable environments on diverse machines, including HPC systems where Apptainer rather than Docker is used [8][10].

### How do I share an R workflow on a high-performance computing cluster?

Use a workflow engine such as Nextflow or Snakemake with per-step Apptainer containers, so the engine handles scheduling and resumption while the images pin every tool version. This is the pattern behind shared genomics workflows built for heterogeneous national computing environments [2] and behind containerized R pipelines with explicit HPC support [8]. Package your R logic as a companion R package that the pipeline calls, as demonstrated by a Nextflow regulatory-network pipeline built around a standalone R package [9].

### Do I need to turn my analysis into an R package?

No, if the analysis is a one-off study, a locked repository with a literate report is sufficient and faster. Yes, if the code contains reusable methods, if you plan community adoption, or if you want Bioconductor-grade dependency checking and documentation. Both patterns coexist in the ecosystem, with packages such as tidyMass and MeTime distributing methods while published analyses drive them from workflow documents [6][5].

### How much documentation should a shared workflow include?

Enough that a new user can rerun the analysis and understand why each major choice was made, not just what was run. In practice this means a README with prerequisites and one run command, a rendered report showing all parameters and QC checkpoints, and comments or vignette text explaining non-default settings. Published best practices emphasize explicit reporting of intermediate outputs and harmonized parameters as the core of transparency [13].

### Can I share a workflow that depends on very large or proprietary data files?

You can share the workflow, but not by putting the data in the repository. Instead, document data provenance, deposit what you legally can in a public archive, provide checksums and download scripts for large public files, and supply small synthetic test data so the pipeline can be validated end to end before real data are attached. Executable vignettes that run on public archive data, as Metabonaut does for LC-MS/MS metabolomics, are the established model for sharing workflows when the full datasets are impractical to redistribute [12].

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is the simplest way to share an R bioinformatics workflow?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "A Git repository containing your scripts or a rendered Quarto report, an renv lockfile, a README with one run command, and a license. This combination pins your R package versions, documents every analytical choice in the report, and gives the reader a single starting point, and it takes under an hour to assemble for a typical analysis."
      }
    },
    {
      "@type": "Question",
      "name": "Should I share my workflow as a Docker container or a Conda environment?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Choose a container when you need complete environment capture, including system libraries and non-R command-line tools, and when collaborators work on laptops or cloud systems. Choose Conda-based environments, typically paired with Snakemake, when your workflow is dominated by external bioinformatics tools and your team wants lightweight, editable environments on diverse machines, including HPC systems where Apptainer rather than Docker is used."
      }
    },
    {
      "@type": "Question",
      "name": "How do I share an R workflow on a high-performance computing cluster?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Use a workflow engine such as Nextflow or Snakemake with per-step Apptainer containers, so the engine handles scheduling and resumption while the images pin every tool version. This is the pattern behind shared genomics workflows built for heterogeneous national computing environments and behind containerized R pipelines with explicit HPC support. Package your R logic as a companion R package that the pipeline calls, as demonstrated by a Nextflow regulatory-network pipeline built around a standalone R package."
      }
    },
    {
      "@type": "Question",
      "name": "Do I need to turn my analysis into an R package?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No, if the analysis is a one-off study, a locked repository with a literate report is sufficient and faster. Yes, if the code contains reusable methods, if you plan community adoption, or if you want Bioconductor-grade dependency checking and documentation. Both patterns coexist in the ecosystem, with packages such as tidyMass and MeTime distributing methods while published analyses drive them from workflow documents."
      }
    },
    {
      "@type": "Question",
      "name": "How much documentation should a shared workflow include?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Enough that a new user can rerun the analysis and understand why each major choice was made, not just what was run. In practice this means a README with prerequisites and one run command, a rendered report showing all parameters and QC checkpoints, and comments or vignette text explaining non-default settings. Published best practices emphasize explicit reporting of intermediate outputs and harmonized parameters as the core of transparency."
      }
    },
    {
      "@type": "Question",
      "name": "Can I share a workflow that depends on very large or proprietary data files?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "You can share the workflow, but not by putting the data in the repository. Instead, document data provenance, deposit what you legally can in a public archive, provide checksums and download scripts for large public files, and supply small synthetic test data so the pipeline can be validated end to end before real data are attached. Executable vignettes that run on public archive data, as Metabonaut does for LC-MS/MS metabolomics, are the established model for sharing workflows when the full datasets are impractical to redistribute."
      }
    }
  ]
}
</script>

## Sources

1. [An evolving computational platform for biological mass spectrometry: workflows, statistics and data mining with MASSyPup64.](https://pubmed.ncbi.nlm.nih.gov/26618079/)
2. [Developing reproducible bioinformatics analysis workflows for heterogeneous computing environments to support African genomics.](https://pubmed.ncbi.nlm.nih.gov/30486782/)
3. [Developing and reusing bioinformatics data analysis pipelines using scientific workflow systems.](https://pubmed.ncbi.nlm.nih.gov/36968012/)
4. [REPRODUCIBLE RESEARCH WORKFLOW IN R FOR THE ANALYSIS OF PERSONALIZED HUMAN MICROBIOME DATA.](https://pubmed.ncbi.nlm.nih.gov/26776185/)
5. [MeTime: an R package for reproducible longitudinal metabolomics data analysis.](https://pubmed.ncbi.nlm.nih.gov/42730207/)
6. [TidyMass an object-oriented reproducible analysis framework for LC-MS data.](https://pubmed.ncbi.nlm.nih.gov/35902589/)
7. [systemPipeR: NGS workflow and report generation environment.](https://pubmed.ncbi.nlm.nih.gov/27650223/)
8. [MStargetR: a reproducible, containerised workflow for end-to-end targeted (MRM/SRM) mass spectrometry data processing in R.](https://pubmed.ncbi.nlm.nih.gov/42791429/)
9. [Reproducible processing of TCGA regulatory networks.](https://pubmed.ncbi.nlm.nih.gov/41114645/)
10. [Natrix: a Snakemake-based workflow for processing, clustering, and taxonomically assigning amplicon sequencing reads.](https://pubmed.ncbi.nlm.nih.gov/33198651/)
11. [GCAC: galaxy workflow system for predictive model building for virtual screening.](https://pubmed.ncbi.nlm.nih.gov/30717669/)
12. [Metabonaut: an open educational resource for learning reproducible, script-based untargeted LC-MS/MS metabolomics.](https://pubmed.ncbi.nlm.nih.gov/42829392/)
13. [A Guide to Enzymatic Targeted Methylation Sequencing Bioinformatics Workflow: Best Practices.](https://pubmed.ncbi.nlm.nih.gov/42848382/)
14. [The FAIRification of research in real-world evidence: A practical introduction to reproducible analytic workflows using Git and R.](https://pubmed.ncbi.nlm.nih.gov/38173166/)