Martha deploy Template

[gdlex4015]

Deployment

Deployments to the dev tier are triggered automatically whenever code is pushed/merged to the dev branch on github.

• Deployments to other tiers are triggered manually by running the
  Martha Manual Deploy
  job on the DSP Jenkins instance. You should follow these steps in order to deploy:

• When the latest code passes tests in CircleCI, it is tagged dev_tests_passed_[timestamp] where [timestamp] is the
  epoch time when the tag was created.

• Create and push a new semver tag for this same commit. You should look at the existing tags
  to ensure that the tag is incremented properly based on the last released version. Tags should be plain semver numbers
  like 1.0.0 and should not have any additional prefix like v1.0.0 or releases/1.0.0. Suffixes are permitted so
  long as they conform to the semver spec.

• Navigate to
  Martha Manual Deploy
  and click the "Build with Parameters" link. Select the TAG that you just created and the tier to which you want to
  deploy.

• You must deploy to each of the following tiers one-by-one and manually test each tier as you deploy to it:

  • dev - Technically, this same commit is already running on dev courtesy of the automatic deployment, but this
    is an important step to ensure that the tag can be deployed properly.
  • alpha
  • perf
  • staging
  • prod - In order to deploy to prod, you must be on the DSP Suitability Roster. You will need to log into the
    production Jenkins instance and use the "Martha Manual Deploy" job to release the same tag to production.

NOTE:

• Each deployment will redeploy all supported versions of functions.
• It is critical that you perform a quick manual test on each tier as you deploy to it because automated testing
  capabilities for Martha are limited.
• It is important that you deploy to all tiers. Because Martha is an "indie service", we should strive to make sure
  that all tiers other than dev are kept in sync and are running the same versions of code. This is essential so that
  as other DSP services are tested during their release process, they can ensure that their code will work properly with
  the latest version of Martha running in prod.

Live Testing

A test suite exists that can be used to verify the functionality of Martha functions running on a specific live or local
environment: local, dev, alpha, perf, staging, prod.

Live Testing Pre-requisites

1. Determine which environment (env) you want to run against.

• Ensure that you have established Bond links between your User account and all supported Providers on that env. You
  can set up these links using the Bond API or by navigating to your User Profile page in Firecloud UI.

1. This test will make a system call to gcloud auth print-access-token. Therefore you will need to:
   1. Make sure you have the GCloud CLI installed.
   2. Ensure that you are logged into your gcloud cli as the same user that you linked in Bond in the previous step.

Running Live Tests

To run the live tests with default settings:

npm run live_test

This will run the tests against locally running Martha functions and will expect Martha to be using the public DRS
resolvers (like dataguids.org) as opposed to the
Mock DRS resolver.

The live_tests accept optional parameters:

npm run live_test -- -- --env=[env] --mock --base_url=[https://...]

There are 3 optional parameters you can pass:

    env         - Can be one of ['dev', 'staging', 'alpha', 'perf', 'prod'].  Used to automatically determine
                  the `base_url`.  Defaults to `local`.
    mock        - If present or set to `true`, then tests will use DRS URLs that are resolvable by the mock-drs
                  service.  If `mock` is absent or set to `false`, tests will use DRS URLs resolvable by the
                  live/public DRS resolvers.
    base_url    - The base URL (protocol and host) where the Martha functions will be called.  Set this option
                  if you want to override the `base_url` derived from the `env` option.  Defaults to
                  `http://localhost:8010/broad-dsde-dev/us-central1`.

NOTE -
The -- -- syntax may seem odd, but it is required in order to
pass arguments
through npm run and into ava.

Examples

Run live_test against the dev environment expecting that environment to be using the Mock DRS resolver:

npm run live_test -- -- --env=dev --mock
npm run live_test -- -- -e dev -m

Run live_test against the staging environment expecting that environment to be using the public DRS resolver:

npm run live_test -- -- --env=staging 
npm run live_test -- -- -e staging

Docker

The Dockerfile for Martha builds a Docker image that, when run, does the following:

• Starts the Google Cloud Functions Emulator
• Deploys all supported Martha functions to the emulator
• Exposes ports: 8008 and 8010
• Handles HTTP requests to the REST API and Functions respectively on the exposed ports

Run the Docker Container

To run the Martha container, whether you are running a locally built image or an image pulled from quay.io, you must
start the container with appropriate port mappings between the host and the container. You can choose whatever host
ports you may require, in the following example ports 58010 and 58008 are used:

docker run -p 58010:8010 -p 58008:8008 quay.io/broadinstitute/martha:latest

Building Docker Images

Public images are published to quay.io for each branch.

To build a new Docker image for Martha:

1. cd to the root of the Martha codebase
2. Run: docker build -f docker/Dockerfile .

Logs (for live app)

• Can be viewed on Google Cloud Platform
  • Go to console.cloud.google.com
  • Select Cloud Functions from the main (on the left side) menu
  • Find the version of the function you want to check
  • Click the vertical three dots and choose "view logs"