⚠️ This registry has been rewritten and is no longer available. Please reference the Origami Registry, instead.
To set up a development environment, download and install docker for mac (https://store.docker.com/editions/community/docker-ce-desktop-mac).
Before we can run the application, we'll need to create a
.env file. You can copy the
sample.env file to
.env and fill in the missing values from the Origami Registry Configuration note in the shared folder on LastPass.
docker-compose to build and start the container:
docker-compose build docker-compose up
Now you can access the app over HTTP on port
The MySQL database is accessible on port 3306, the settings for which are in the
We have a series of Make tasks to simplify working with local assets. To install all the dependencies from
To compile all assets you can run:
And finally to watch and compile front-end assets during development, you can run:
To work with the Registry locally you will need some data in your local database. From a completely empty database, the best thing to do is grab a copy from someone else. This update script might work but errors if the tables it expects are not there.
To run the update script locally, you will need to SSH into the Docker VM and the container for the Registry:
docker ps docker exec -i -t origamiregistry_web_1 bash
You should now be in a bash command line for the registry app. You can now run the update registry script with the following command:
Follow these steps to deploy to the qa application:
# Login to Heroku command line tool HEROKU_ORGANIZATION='financial-times' heroku login --sso # Login to Heroku's Docker registry docker login --username=_ --password=$(heroku auth:token) registry.heroku.com # Build our Docker image and tag it for the qa app on Heroku git describe --tags > ./appversion && docker build -t registry.heroku.com/origami-registry-qa/web . && rm -f ./appversion # Push our Docker image to the qa app on Heroku docker push registry.heroku.com/origami-registry-qa/web
When ready to promote from the qa application to the production application, follow these steps:
# Rename our Docker image for the eu app on Heroku docker tag registry.heroku.com/origami-registry-qa/web registry.heroku.com/origami-registry-eu/web # Push our Docker image to the eu app on Heroku docker push registry.heroku.com/origami-registry-eu/web
The Origami Registry architecture diagram can be found in Google drive.
We've outlined some common issues that can occur when running the Registry locally:
This is likely because you're on a different network which doesn't allow you access to the private FT repositories. Make sure you're connected to the internal network/wifi, to make sure
docker-compose has access to the correct network.
There is a row in the
meta table of the database (key:
cron_running_host) that will prevent the discover script from running more than once at any given time. If the discover script has stopped running this is likely because a previous update didn't finish or failed while running and the
cron_running_host row did not get deleted from the table. To fix this, log in to the production database (login details are in Heroku config vars:
CLEARDB_DATABASE_URL), and delete the
cron_running_host row from the
If a new component has been created or one has been updated to be an Origami component, the Registry might not pick it up as an Origami component on the next run of the discovery script like it does with new releases. This is due to how often the Registry scans Origami components vs. non-Origami components. The Registry scans all repositories in the Git sources hourly, but only looks at new releases of already valid Origami components, whereas non-Origami components are checked only every 48 hours.
To speed up the discovery of a new Origami component, update the module in the
components table of the database by searching the
module_name and changing the
is_origami column to
The Origami Sensei is a Slack Webhook that announces new releases into the FT Origami Slack channel. It's configured in the Slack Apps settings, by going to
Custom Integrations >
Incoming Webhooks and searching for
Origami. If it's stopped announcing in the channel it's likely that the webhook has become disabled and will need to be re-enabled.
There are also settings for which webhook to point to in the Heroku config vars:
In dev, these are configured in the
.env file. In live, it's
PORT: Port used by Apache to serve HTTP traffic. Must match container's exposed ports config. Should not be configured explicitly on Heroku
DATABASE_URL: URL of the MySQL instance to use. In dev, this is a linked container, in live, it's a ClearDB addon (TODO: Not sure why we can't allow Heroku to simulate the ClearDB container in dev)
SENTRY_DSN: URL of the Sentry project to use to collect runtime errors, exceptions and log messages
IS_DEV: Boolean to indicate whether the app should be considered to be running in a dev environment. If true, will suppress some notifications and change error reporting behaviour.
GITHUB_CREDENTIALS: Used to connect to Github for the component discovery process.
SLACK_WEBHOOK: "Incoming Webhook" URL from Slack to which to post notifications of new discovered modules
SLACK_CHANNEL: Slack channel to post new module notifications in
BUILD_SERVICE_HOST: Hostname of the build service to use for fetching module metadata
VIEW_CACHE_PATH: Path on disk to use to cache view templates in Twig
DEBUG_KEY: String, if set in a
DebugHTTP header, will set dev mode to true for that request only.
The following files are used in build, test and deploy automation:
.dockerignore: used to ignore things when adding files to the Docker image. Generally this will be the same as the
.gitignorefile as the build happens at the container creation time. See the
Dockerfilefor more info.
The Financial Times has published this software under the MIT license.