Amphtml: Publish Storybook with releases

Created on 2 Nov 2020  路  6Comments  路  Source: ampproject/amphtml

30926 introduces a gulp task to generate a static Storybook. This allows reviewers to test components on a UI on every change (like for a PR here).

gulp storybook --build

This generates a directory: examples/storybook/, containing accessible dirs preact/ and amp/.

We can publish this directory to the CDN to allow manual testing of components for the latest/any released build, like: https://cdn.ampproject.org/components

@ampproject/wg-infra
@ampproject/wg-components

Soon Feature Request infra

All 6 comments

/cc @ampproject/wg-outreach

This shouldn't be too difficult to implement, I believe this would only require a configuration change to the CDN (_maybe_ some code change, but probably not) - two questions that need an answer are:

  1. Would we want this to be affected by opt-in cookies? (I think it makes sense)
  2. Would we want to have diversion experiments on this (i.e., send some % of traffic to different versions, or send everyone to the Stable version unless they have an opt-in cookie)

As for adding it to the release process - see the gulp release code, it should just be added there

I'll wait for @kristoferbaxter to weigh in with a more official answer, but this is what my instinct tells me:

  1. Would we want this to be affected by opt-in cookies? (I think it makes sense)

Agreed, the opt-in channel should be reflected.

  1. Would we want to have diversion experiments on this (i.e., send some % of traffic to different versions, or send everyone to the Stable version unless they have an opt-in cookie)

This is not a production environment, but a testing tool for publishers to tinker with. So I'm not sure what value is created by diverting to a certain % of traffic. If it's not difficult to have this behavior with the current CDN configuration, I'd say that traffic should not be randomly diverted. In any case when loading the amp environment, the JS binaries are loaded from cdn.ampproject.org, which would still be served like they do at the moment.

  1. Would we want this to be affected by opt-in cookies? (I think it makes sense)

Potentially, but with the ability to override would be prudent (in the Storybook UI).

  1. Would we want to have diversion experiments on this (i.e., send some % of traffic to different versions, or send everyone to the Stable version unless they have an opt-in cookie)

I don't think we should do this by default, but instead include a dropdown in the storybook UI (where TBD) that allows the visitor of the storybook to choose which branch to use (this could also be used to help isolate issues between releases).

Other options welcome too for the same effect.

If I understand correctly, these are the changes to make:

CDN

  1. Ensure that CDN serves same Storybook files as opt-in. (@danielrozenberg Probably nothing to do here?)

Release

  1. Add build step to gulp release.

Storybook

  1. Allow setting opt-in cookie.
  2. Allow picking /rtv/.../*.js binaries to select specific release.

(I don't think the required Storybook changes should block this, but @kristoferbaxter can let me know if he disagrees.)

No disagreement here! Thanks @alanorozco.

Was this page helpful?
0 / 5 - 0 ratings