|
| 1 | +# Note: Chromatic is a separate workflow for coder.yaml as suggested by the |
| 2 | +# chromatic docs. Explicitly, Chromatic works best on 'push' instead of other |
| 3 | +# event types (like pull request), keep in mind that it works build-over-build |
| 4 | +# by storing snapshots. |
| 5 | +# |
| 6 | +# SEE: https://www.chromatic.com/docs/ci |
1 | 7 | name:"Chromatic" |
2 | 8 |
|
| 9 | +# Chromatic works best with push events, not pull_request or other event types. |
3 | 10 | on:push |
4 | 11 |
|
5 | 12 | jobs: |
6 | 13 | chromatic-deployment: |
| 14 | +# REMARK: this is only used to build storybook and deploy it to Chromatic. |
7 | 15 | runs-on:ubuntu-latest |
8 | 16 |
|
9 | 17 | steps: |
10 | 18 | -uses:actions/checkout@v3 |
11 | 19 | with: |
12 | | -fetch-depth:0# <-- required by Chromatic for build-over-build history |
| 20 | +# Required by Chromatic for build-over-build history, otherwise we |
| 21 | +# only get 1 commit on shallow checkout. |
| 22 | +fetch-depth:0 |
13 | 23 |
|
14 | 24 | -name:Install dependencies |
15 | 25 | run:cd site && yarn |
|
28 | 38 | # This is a separate step for mainline only that auto accepts and changes |
29 | 39 | # instead of holding CI up. Since we squash/merge, this is defensive to |
30 | 40 | # avoid the same changeset from requiring review once squashed into |
31 | | -# main. |
| 41 | +# main. Chromatic is supposed to be able to detect that we use squash |
| 42 | +# commits, but it's good to be defensive in case, otherwise CI remains |
| 43 | +# infinitely "in progress" in mainline unless we re-review each build. |
32 | 44 | -name:Publish to Chromatic (mainline) |
33 | 45 | if:github.ref == 'refs/heads/main' |
34 | 46 | uses:chromaui/action@v1 |
|