synapser 1.0.0+ dev/staging/validation/release

Owned by Thomas Yu
Last updated: Sept 10, 2023

This document attempts to cover development and release practices for the synapser projects. As of synapser 1.0.0+, PythonEmbedInR is no longer used.

Github repositories

The code base for Synapse R client (wrap Python client) can be found at https://github.com/Sage-Bionetworks/synapser .

Branches

  • master: tracking latest release

  • develop: tracking latest development work

  • release candidate branches: for each release, a new release candidate branch will be created with name set to the version to release (v1.0-rc).

Development and Release

Releasing a new version of synapser is a process that involves client engineers, product manager, validators, and end users.

Step 1: Identifying the next release

This step starts with client engineers and product manager going over R JIRA tickets and determining their priority, tagging them with the new release version, and assigning them to client engineers.

Step 2: Development

Develop work will be checked into develop branch. 

  1. Fork https://github.com/Sage-Bionetworks/synapser

  2. Checkout a new branch to work on a feature / Jira

  3. GitHub Actions are configured in the repositories. Every push will build and test your changes in your forked repo (see the GitHub Actions tab of the repo). On your fork of the synapser repo, add each of the following secrets, the values can be obtained from the "Python Client dev stack openssl keys" entry of LastPass. These allow a test configuration to be installed during builds which enables vignette integration tests to run against test services. 

    1. encrypted_d17283647768_iv

    2. encrypted_d17283647768_key

  4. Once your change is ready for review, create a Pull Request with 

    1. base fork: https://github.com/Sage-Bionetworks/synapser

    2. base: develop

    3. head fork: <your Github account>/synapser

    4. compare: <your feature branch>

  5. Code view and reviewer merges your change

References:

Configuration

Add this file to your home directory, uncommenting headers and fields as necessary. Heres an example:

Changing The Version of the Underlying Python Client

The synapser package 'wraps' a specific version of the Synapse Python Client, specified in R/zzz.R, and tools/installPythonClient.R for example:

PYTHON_CLIENT_VERSION <- '2.7.0'

synapser will look for the specified version in PyPI. Like all R packages, synapser has embedded reference doc's.  These doc's are in a LaTeX-like format, have the file suffix ".Rd" and go in a directory called man/.  This is a "source" folder which the package build process uses as input. 

Ideally in the synapser package we would generate a perfect .Rd document for each Python command that we wrap in an R command.  We can certainly generate a valid LaTeX file and copy over the content of the Python docstrings.  However we cannot guarantee that the doc's will be perfect, since the docstrings often have code examples and other verbiage in Python.  Our strategy is to generate draft .Rd files and perform a manual step of finalizing them.  The procedure is as follows:

  1. Build the R package.  The draft .Rd files are written into a folder called auto-man/

    R CMD INSTALL .

  2. Perform a git diff to see what auto-generated files have been added or changed.  The changes should be a small fraction of the overall documents.  Manually transfer the new documents and changes to the man/ folder, editing as needed. For example make sure that any python examples embedded within Python docstrings are properly translated into R equivalent code in the generated documentation.

  3. git commit both the auto-generated and manually curated files.

Note: Make sure to add in new Rd files.

Step 3: Deploy Staging

Once all JIRA tickets for the new release version are RESOLVED, we are ready to deploy staging version for validation process.

  1. Create a new release candidate branch from develop with branch name as the version to release (v1.0-rc)

  2. Update the docs in the release candidate branch:

    1. ensure you have the R pkgdown package installed (on a Mac you may need to brew install harfbuzz, fribidi, and pandoc if you haven't already)

    2. Update the changelog contained in NEWS.md

    3. Update the version in the DESCRIPTION file, as the version is reflected in the generated documentation.

    4. from the repo directory run the following command:

    5. Review the changes by inspecting docs/index.html file.

    6. Commit the changes to the docs directory. When this release branch is validated and merged to master it will automatically publish to https://r-docs.synapse.org via GitHub Pages.

  3. Create a new staging release

    1. Go to the releases of the appropriate repo

    2. Click the "Draft a new release" button and fill the following values:

      Tag version: X.Y-rc where X.Y where X.Y is the release version (e.g. 0.11-rc)
      Target: the previously created vX.Y-rc branch
      Release title: Same as tag version (X.Y-rc)

      Important: Check the "This is a pre-release" checkbox. This will cause the release to be deployed to a staging ran.

    3. Hit the publish button, this will trigger a GitHub Action that will test and deploy the staging release to http://staging-ran.synapse.org/

  4. Notify validators about the available version. The validation version will be in format <version-to-build>.<build-number> (For example: 1.0.87, for build number 87).

Step 4: Validation

Validators can download and/or install the new pre-release version via install.packages() (recommended) or using devtools (not-recommended). After installing the pre-release version, a validator can validate the JIRA tickets that they were assigned and change their status to CLOSE or REOPEN.

Option 1: Installing from Staging RAN

Staging RAN Repo: http://staging-ran.synapse.org

staging-ran

Option 2: Using devtools

devtools-staging

Step 5: Patch Staging

When a critical bug is found during validation, and it needed to be addressed before releasing, a patch need to go into "staging" without changing the <major>.<minor> release version.

  1. A client engineer fix a bug, run private build, and create Pull Request to the release branch (v1.0-rc)

  2. After the Pull Request is merged, start the staging build to update the artifacts. Please see Step 3 to recreate a staging build.

  3. Notify the validator to re-validate the ticket with the new artifact.

Step 6: Release

After all JIRA issue are CLOSED, the new version is ready to be released. Creating a production deployment is similar to the staging deployment and is accomplished by publishing a GitHub release:

  1. Go to the releases of the appropriate repo

  2. Click the "Draft a new release" button and fill the following values:

    Tag version: X.Y where X.Y is the release version (e.g. 0.11)
    Target: the previously created vX.Y-rc branch
    Release title: Same as tag version (X.Y)

    Do NOT check the "This is a pre-release" checkbox.


  3. Hit the publish button, this will trigger a GitHub Action that will test and deploy the production release to http://ran.synapse.org/

  4. Merge the develop branch to the master branch.

Step 7: Users install the released version

Option 1: Installing from RAN

RAN Repo: http://ran.synapse.org

ran

Option 2: Using devtools

devtools-prod

Publishing Documentation 

Users come to the synapser package through:

Each of the location above should include general information about synapser package and how to download it. 

The package docs site (3) should be the central place to access all available documents. Each of the site above should link to it.

As a part of the release process, we generate and update the documents.

  • While building artifacts and pushing them to staging ran, we will generate docs and merge back to release candidate branch.

  • When we release the artifact to prod ran, we merge release candidate branch to master. This will update the docs site.

CI/CD configuration

As discussed above, the CI/CD for synapser is driven through GitHub Actions. The build is contained in the contained build.yml workflows of the respective repositories (synapser).

References:

  • R package docs site tools: 

  • Github Pages instructions: