Pro tips

This chapter illustrates some hidden features that you can use to enhance your workflow when using FeaturePeek. Some of these tips apply to when you're opening up a PR in GitHub, while others apply as options within the FeaturePeek UI itself.

Create multiple deployments per pull request

With FeaturePeek, you're able to spin up multiple different frontends 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 frontends you'd want to spin up per PR — in most cases, you'll have only one or two per PR.

You can set this very easily by appending an app definition to your peek.yml file. You can add as many app definitions as you'd like.

version: 2
main:
type: docker
port: 3000
storybook:
type: static
path: /.out

Above, the two app definitions are main and storybook.

You'll need to have a build step for each app in your CI pipeline. It's recommended to run your build workflows in parallel so that they spin up as quickly as possible.

After each app builds in your CI pipeline, you'll need to ping FeaturePeek after each, with the -a flag set the name of your app definition you defined in peek.yml, e.g. bash <(curl -s https://peek.run/ci) -a storybook.

Set the entry path when you create the pull request

Your deployment's entry path is the route that loads initially when your reviewers click on the link in GitHub, Slack, or your team's dashboard in FeaturePeek.

If you only made changes to your frontend's /about page, then you can set your entry path to be /about so that your reviewers will land there automatically instead of having to navigate on their own.

To set the entry path at the same time as you create the pull request, simply include @featurepeek /entry/path in the description of your pull request body, where /entry/path is the route to your desired path.

entry path

For more details, read our changelog post about this feature.

Use the peek.run URL shortener

If you have a URL like https://dashboard.featurepeek.com/peek/a1b2c3, you can shorten this to peek.run/a1b2c3 — it'll redirect to the full dashboard URL.

The document fragment gets preserved too: peek.run/a1b2c3#/about will take you to the deployment's /about page.

Only spin up deployments for certain branches

Your team may not desire a deployment preview (and subsequently, pull request comments) for every single pull request. Pull requests with trivial changes — or changes that don't affect your frontend at all — aren't good candidates for FeaturePeek deployments.

You can specify a branch pattern in your project settings to only create deployment previews for PRs whose branches match a given regular expression.

For example, if you only want FeaturePeek to create deployment previews for branches that start with "peek/", you'd set the branch pattern to be ^peek/. If you only want FeaturePeek to create deployment previews for branches that end with "-peek", you'd set it to -peek$.

Of course, you may push a PR to GitHub that doesn't match this pattern, only to realize later that you do in fact want a deployment for it. In that case, you should create the FeaturePeek deployment manually.

Spin up deployments manually

If you specified a branch pattern for your project, not all of your deployments will spin up automatically.

You may push a branch that doesn't match your project's branch pattern, only to realize later that you do in fact want a deployment for it. In that case, edit the body of your PR description to include @featurepeek -- this will create a deployment and post the link on this pull request.