Thanks for your interest in contributing to workflowr. Here are some guidelines to help make it easier to merge your Pull Request:
devtools::test() to run the tests
If you’re new to submitting Pull Requests, please read the section Contribute to other projects in the tutorial A quick introduction to version control with Git and GitHub.
To contribute to workflowr, follow these steps to setup a development environment:
Fork GitHub repository and clone to your local machine
# Install package dependencies
if (!requireNamespace("remotes", quietly = TRUE))
remotes::install_deps(dependencies = TRUE)
# Install developlment-only dependencies
# Install local copy of workflowr
For the most part, I try to follow the guidelines from R packages by Hadley Wickham. The unit tests are performed with testthat, the documentation is built with roxygen2, and the online package documentation is created with pkgdown.
Minimal continuous integration testing is performed by GitHub Actions for each push to the repository. Extensive continuous integration testing is performed at scheduled intervals in workflowr-pkg-tests. Code coverage is calculated with covr and Codecov. The online package documentation is automatically generated by running pkgdown from GitHub Actions and pushing to the gh-pages branch.
The template files used by
wflow_start() to populate a new project are defined in the list
templates in the file
R/infrastructure.R. The RStudio project template is configured by
inst/rstudio/templates/project/wflow_start.dcf. The repository contains the files
LICENSE.md to both adhere to R package conventions for defining the license and also to make the license clear in a more conventional manner (suggestions for improvement welcome). The directory
scripts/ contains convenience scripts for maintaining the R package. The remaining directories are standard for R packages as described in the manual Writing R Extensions.
Convenience scripts for maintaining the package are located in
scripts/. These are not included in the package tarball for distribution. They are all intended to be executed from the root directory of the package. The convenience scripts include:
R CMD build and
R CMD check
bump-version.R bumps the version across all the necessary package files
contribute.R performs some basic checks that should be run before contributing a Pull Request
document.R regenerates the documentation
gather-dependencies.R extracts the dependencies from
DESCRIPTION to create the vector
R/zzz.R (which is used to confirm that all the packages that workflowr needs are properly installed)
sed.sh performs search/replace for all R files in the package
Bump version with scripts/bump-version.R
Update NEWS.md: Check
git log and make sure to reference GitHub Issues/PRs
Check spelling with
spelling::spell_check_package() and update
inst/CITATION as needed
Run scripts/document.R to update Rd files, install the package locally, and preview the online documentation with pkgdown (No need to commit
docs/ because the pkgdown site is rebuilt and deployed automatically by GitHub Pages after each push)
Run scripts/build.sh to confirm tests pass locally
Test on rhub:
rhub::validate_email(). Copy-paste token from email into R console
rhub::check_for_cran(platform = "ubuntu-gcc-devel")
rhub::check_for_cran(platform = "solaris-x86-patched")
Test on winbuilder:
git commit -am "Bump version: x.x.x.x -> x.x.x"
git push origin main and wait for CI builds to pass
Build tarball with
R CMD build . and upload to CRAN submission site. You will receive an email to request confirmation, then an email confirming the package was submitted, and then an email with the test results. Once it is accepted to CRAN, monitor the check results for any surprise errors. Also, these builds are when the binaries are built for Windows and macOS, so they aren’t available until they are finished. You will receive an email once all the Windows binaries are available for download (devel, release, oldrel).
You can monitor the status of the CRAN submission with the foghorn package:
foghorn::cran_results(pkg = "workflowr")
git tag -a vx.x.x. Summarize NEWS.md entry into bullet points. Run
git tag -l -n9 for past examples. Push with
git push origin --tags.
Make a release. On GitHub, go to Releases -> Tags -> Edit release notes. Name the release “workflowr x.x.x” and copy-paste the Markdown entry from NEWS.md.