Updates and CI
Stay up to date automatically by adding the CLI to your Continuous Integration process
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 formytarget
- Preserve your existing
interplay.config.js
settings file andtargets.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