Origami Bower Registry

Decommissioned, Origami components are now published to the npm registry: Install Financial Times GitHub repositories as Bower components. See the production service for API information.

Table Of Contents

• Requirements
• Running Locally
• Configuration
• Adding Organisations
• Operational Documentation
• Testing
• Deployment
• Monitoring
• Trouble-Shooting
• License

Requirements

Running Origami Bower Registry requires Node.js 12.x and npm.

Running Locally

Before we can run the application, we'll need to install dependencies:

npm install

Run the application in development mode with

make run-dev

Now you can access the app over HTTP on port 8080: http://localhost:8080/

Configuration

We configure Origami Bower Registry using environment variables. In development, configurations are set in a .env file. In production, these are set through Heroku config. Further documentation on the available options can be found in the Origami Service documentation.

Required everywhere

• AWS_ACCESS_KEY: The API key used to publish packages to S3.
• AWS_SECRET_KEY: The secret key used to publish packages to S3.
• GITHUB_SECRET: The secret used when communicating with the Github Webhooks.
• GITHUB_TOKEN: The oauth token to use when communicating with the Github API.
• NODE_ENV: The environment to run the application in. One of production, development (default), or test (for use in automated tests).
• PACKAGE_DATA_STORE: The location of the JSON packages data that powers the service. This should be a URL.
• PORT: The port to run the application on.
• S3_BUCKETS: Comma-separated S3 bucket names to publish packages to.

Required in Heroku

• FASTLY_PURGE_API_KEY: A Fastly API key which is used to purge URLs (when somebody POSTs to the /purge endpoint)
• GRAPHITE_API_KEY: The FT's internal Graphite API key.
• PURGE_API_KEY: The API key to require when somebody POSTs to the /purge endpoint. This should be a non-memorable string, for example a UUID
• REGION: The region the application is running in. One of QA, EU, or US
• SENTRY_DSN: The Sentry URL to send error information to.

Required locally

• GRAFANA_API_KEY: The API key to use when using Grafana push/pull

Headers

The service can also be configured by sending HTTP headers, these would normally be set in your CDN config:

• FT-Origami-Service-Base-Path: The base path for the service, this gets prepended to all paths in the HTML and ensures that redirects work when the CDN rewrites URLs.

Adding Organisations

In order for the Origami Bower Registry to crawl a GitHub organisation, you need to complete a few steps:

1. Add the GitHub organisation name to the githubOrganisations array in index.js

2. Set up an organisation webhook:

   1. Navigate to https://github.com/organizations/<YOUR-ORG>/settings/hooks

   2. Click the Add webhook button

   3. Set the Payload URL to https://origami-bower-registry.ft.com/packages/refresh

   4. Set the Content type to application/x-www-form-urlencoded

   5. Set the Secret to a value given to you by the Origami Team. (Ask them to give you access to the Bower Registry GitHub Webhook Secret LastPass note)

   6. Check the Let me select individual events radio

   7. Uncheck all of the event type checkboxes that appear, except Repository – which will alert the Bower Registry when a repository is created, deleted, publicised, or privatised

   8. Save the webhook by clicking the Add webhook button at the bottom of the page

3. Celebrate!

Operational Documentation

The source documentation for the runbook and healthcheck endpoints are stored in the operational-documentation folder. These files are pushed to CMDB upon every promotion to production. You can push them to CMDB manually by running the following command:

make cmdb-update

Testing

The tests are split into unit tests and integration tests. To run tests on your machine you'll need to install Node.js and run make install. Then you can run the following commands:

make test              # run all the tests
make test-unit         # run the unit tests
make test-integration  # run the integration tests

You can run the unit tests with coverage reporting, which expects 90% coverage or more:

make test-unit-coverage verify-coverage

The code will also need to pass linting on CI, you can run the linter locally with:

make verify

We run the tests and linter on CI, you can view [results on CI][ci]. make test and make lint must pass before we merge a pull request.

Deployment

The production (EU/US) and QA applications run on Heroku. We deploy continuously to QA via [CI][ci], you should never need to deploy to QA manually. We use a Heroku pipeline to promote QA deployments to production.

You can promote either through the Heroku interface, or by running the following command locally:

make promote

Monitoring

• Grafana dashboard: graph memory, load, and number of requests
• Pingdom check (Production EU): checks that the EU production app is responding
• Pingdom check (Production US): checks that the US production app is responding
• Sentry dashboard (Production): records application errors in the production app
• Sentry dashboard (QA): records application errors in the QA app
• Splunk (Production): query application logs

Trouble-Shooting

We've outlined some common issues that can occur in the running of the Origami Bower Registry:

What do I do if memory usage is high?

For now, restart the Heroku dynos:

heroku restart --app origami-bower-registry-eu
heroku restart --app origami-bower-registry-us

If this doesn't help, then a temporary measure could be to add more dynos to the production applications, or switch the existing ones to higher performance dynos.

What if I need to deploy manually?

If you really need to deploy manually, you should only do so to QA (production deploys should always be a promotion). Use the following command to deploy to QA manually:

make deploy

License

The Financial Times has published this software under the MIT license.