Every FeaturePeek project has a
peek.yml file at its repo root. The peek.yml file defines:
- The number of front-ends in your repo. With FeaturePeek, you're able to spin up multiple different front-ends for each pull request. For example, your main app could be a dockerized Node.js app, but you also build static assets for Storybook. If you have a monorepo, you may have a few different front-ends you'd want to spin up per PR — in most cases, you'll have only one or two per PR.
- The type of each front-end's architecture. This specifies whether your project is a static or Docker project.
- Configuration details about each front-end. For static front-ends, you'll supply the directory of the static build. For Dockerized front-ends, you'll supply the exposed port.
peek.yml file must contain the version and at least one app definition as top-level items. Below is an example
peek.yml file that supports two front-ends: one Dockerized app, and one static app.
version: 2 main: type: docker port: 3000 storybook: type: static path: /.out
The version helps maintain backwards compatibility with previous FeaturePeek versions. You should set this value to be
Each app definition specifies the
type of front-end architecture, and either the
path of the static build or the exposed
port of the containerized service.
typeshould be either
docker. Read the difference between static and Docker builds if you need help deciding which fits best for your front-end.
pathis the path to your statically built assets, relative to your repo root. You should only include this key if your
portis the exposed port of your front-end's Dockerfile. You should only include this key if your
You can call each front-end app anything you'd like — in the example above, we call them
storybook. The keys correspond to the
-a flag in the CI command. If you do not pass an
-a flag, the first app definition in the
peek.yml file will be used.
You might be wondering how FeaturePeek knows which Dockerfile to look at, or which
yarn command to run to build static assets. This information comes from a previous step in your CI pipeline — read Running the CI Command for more information.
Difference between static and Docker builds
Static projects are very lightweight and can be served out of a basic HTTP server like nginx or Apache.
Dockerized projects typically run a server-side service (like Node.js, PHP, etc) to generate HTML dynamically, rather than depending on the browser (client) to render HTML. If you use a framework like Django or Ruby on Rails to create your HTML templates, you'll want to make sure you Dockerize your project so that it can run on FeaturePeek.
Unlike statically-built projects, Dockerized projects have access to run-time environment variables. These are helpful for setting secrets that you don't want to commit to your git repo, or for setting values that vary by deployment. You can change these values dynamically inside your FeaturePeek dashboard without having to rebuild your application.
Note: Sometimes, projects build inside Docker even though the built app only serves static assets — for example, apps that spin up an Express server only to serve files out of a static directory.
If your project does not depend on dynamic routes, you should instead configure your project to be static. Your FeaturePeek environment start-up times will be faster.