I've hacked together a prototype of using Storybook for a few DiscoveryStream components. An example of what this looks like is at <https://dmose.github.io/activity-stream/>. The PR is at <https://github.com/mozilla/activity-stream/pull/4923/files>, and it's failing to pass the CI only because I didn't set it up with credentials that would allow it to push to master. Doing that cleanly would be something like Left as an exercise for the next owner of this bug are: * securely making the credentials available to push this automatically during CI; https://wiki.mozilla.org/GitHub and https://wiki.mozilla.org/GitHub/Repository_Security are likely to be relevant here. Note, however, that we don't necessarily have to push the Storybook static build into the same repo, and the storybook-deployer allows it to be pushed to S3, which might end up making it easier. * making the build turn red if visual regressions are found. https://storybook.js.org/docs/testing/automated-visual-testing/ points to lots of possible avenues here, including Percy, as mentioned above by Jason.
Bug 1531104 Comment 4 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I've hacked together a prototype of using Storybook for a few DiscoveryStream components. An example of what this looks like is at <https://dmose.github.io/activity-stream/>. The PR is at <https://github.com/mozilla/activity-stream/pull/4923/files>, and it's failing to pass the CI only because I didn't set it up with credentials that would allow it to push to master. Doing that cleanly would be something like Left as an exercise for the next owner of this bug are: * securely making the credentials available to push this automatically during CI; https://wiki.mozilla.org/GitHub and https://wiki.mozilla.org/GitHub/Repository_Security are likely to be relevant here. Note, however, that we don't necessarily have to push the Storybook static build into the same repo, and the storybook-deployer allows it to be pushed to S3, which might end up making it easier. * making the build turn red if visual regressions are found. https://storybook.js.org/docs/testing/automated-visual-testing/ points to lots of possible avenues here, including Percy, as mentioned above by Jason. * making a link to the storybook for any built commit in the PR appear in the PR page.
I've hacked together a prototype of using Storybook for a few DiscoveryStream components. An example of what this looks like is at <https://dmose.github.io/activity-stream/>. The PR is at <https://github.com/mozilla/activity-stream/pull/4923/files>, and it's failing to pass the CI only because I didn't set it up with credentials that would allow it to push to master. Doing that cleanly would be something like Left as an exercise for the next owner of this bug are: * securely making the credentials available to push this automatically during CI; https://wiki.mozilla.org/GitHub and https://wiki.mozilla.org/GitHub/Repository_Security are likely to be relevant here. Note, however, that we don't necessarily have to push the Storybook static build into the same repo, and the storybook-deployer allows it to be pushed to S3, which might end up making it easier. * making a link to the storybook for any built commit in the PR appear in the PR page. Worth spinning out to other bugs: * making the (Travis) build turn red if visual regressions are found. https://storybook.js.org/docs/testing/automated-visual-testing/ points to lots of possible avenues here, including Percy, as mentioned above by Jason. * making Treeherder (Tier ?) turn red if visual regressions are found. * making Phabricator deploy Storybook on pushes to m-c