Updates and CI

Once you have created your CLI settings you can keep Interplay (and Figma) up to date with changes in your repo by saving your settings files and running the CLI again, either locally against a local copy of your repo or as part of your Continuous Integration process.

Running the CLI locally

To setup the CLI to import your components for the first time, please see Importing from your Repo

Once you have saved a settings file for the CLI, you can run it repeatedly to import the latest code and component configuration. You can run the build, parse and deploy in one command:

interplay

Each time you deploy a new set of component config to Interplay, the changes since the last import are calculated and a commit is created in your design system history.

Continuous Integration (CI)

By checking your interplay settings file into your code repo, you can call the Interplay CLI as part of your CI process. This is essentially the same as running the CLI locally, only the CLI is running against your repo on your build server.

For example, here is a Github workflow file to automatically install and run the CLI to update components in Interplay each time there is a commit to the 'main' branch of the repo.

It makes use of the INTERPLAY_TOKEN auth key which is available in your design system settings in Interplay.

name: Interplay CLI
on:
  push:
    branches:
      - main
jobs:
  interplaycli:
    runs-on: ubuntu-latest
    steps:
      - name: "Checkout"
        uses: actions/checkout@v2
      - name: "Setup Node.js"
        uses: actions/setup-node@v1
        with:
          node-version: 16

      - name: "Install deps inc peers"
        run: npm ci

      - name: "Install CLI"
        run: npm install -g @interplay/cli @interplay/cli-plugin-react

      - name: "Run CLI"
        run: interplay
        env:
          INTERPLAY_TOKEN: ${{ secrets.INTERPLAY_TOKEN }}

Deploying to different design systems in Interplay

Sometimes it is useful to deploy to different design system projects in Interplay, especially as part of CI. For example, you might have:

A “work in progress” design system that is accessed only by the Design system team

A “production” design system that is published for the whole company to use

There are two ways you can set this up - either by setting up multiple deploy targets or by overriding the projectId at runtime.

Configuring multiple targets

You can configure the CLI with multiple deployment targets using the .interplay/targets.json file created by the CLI. Each target is a design system in Interplay.

The file contains configuration for each target, and you specify which target you are using at runtime with the --targets flag on the CLI commands. Without this flag the CLI uses the default target created when you first ran interplay init during setup.

To add a new target, initialise the CLI again with a new target name set:

interplay init --target mytarget

Doing this will:

Popup the browser for you to choose or initialise the new target design system in Interplay

Populate your .interplay/targets.json file with this new team (workspace) and project for mytarget

Preserve your existing interplay.config.js settings file and targets.json content for other targets.

Check-in your updated targets.json file and you can use the targets flag to deploy to your different design systems as you run the CLI commands:

//run individual stages for default target as usual
interplay build
interplay parse
interplay deploy

//run build, parse and deploy in one step for default target
interplay


//run individual stages for mytarget
interplay build --target mytarget
interplay parse --target mytarget
interplay deploy --target mytarget

//run build, parse and deploy stages in one step for mytarget
interplay --target mytarget

Passing teamId and projectId at runtime

As an alternative to using the targets option, you can pass in the workspace (teamId) and project (projectId) using environment variables. You can find the relevant IDs to use in the URL of your project:

https://app.interplay.io/app/<teamId>/p/<projectId>/components

You can then pass these values at the command line or in your CI environment e.g.

INTERPLAY_TEAMID=ck9xzbldg000002s64r INTERPLAY_PROJECTID=sRD2olJSME interplay

You will see a message in the CLI output to say that these values are being applied to override any values found in the local targets.json file.

Using different environment variables with the CLI commands, you can to configure your CI process to import to different design systems in Interplay.

Design system permissions

If you are working with multiple design systems in Interplay you may want to restrict access to your “work in progress” design system(s) so that consumers of your design system only see the one you intend.

You can set design system level permission on our paid plans. Please see Design System Permissions for more details