test: e2e test website accountPayment loggedIn, includes magic.link testMode support in test-e2e job only#1754
Conversation
…om .env and uses gh action secrets
This reverts commit a504193.
…ar keys, not rewrite with values from env
…sed in ci website workflow)
…_MAGIC... env vars
| }; | ||
|
|
||
| /** | ||
| * @param {Object} [props] |
There was a problem hiding this comment.
This was required for next build to build locally for me with tsc, and makes sense to clarify that the argument destructuring wont work if props === undefined
| @@ -1,5 +1,6 @@ | |||
| const API = /** @type {string} **/ (process.env.NEXT_PUBLIC_API); | |||
| const MAGIC_TOKEN = /** @type {string} **/ (process.env.NEXT_PUBLIC_MAGIC); | |||
| const MAGIC_TESTMODE_ENABLED = Boolean(process.env.NEXT_PUBLIC_MAGIC_TESTMODE_ENABLED); | |||
There was a problem hiding this comment.
I think that we're relying on miniflare/wrangler to replace this NEXT_PUBLIC_MAGIC_TESTMODE_ENABLED (and NEXT_PUBLIC_MAGIC) is one reason you have to explicitly tell miniflare about your env vars either through the env file or through the --binding KEY=VALUE flags I added when the website ci workflow invokes npm -w '@web3-storage/api' start. I think maybe miniflare devs would be hesitant to automatically pass everything through from miniflare env without an allowlist because it could lead to a developers secrets getting into the build without explicit configuration that thats what they'd want.
|
the main new thing I'd point out, which I think made the code clearer, was to reify the fact that that there are two distinct kinds of of 'magic.link bypasses'
|
yusefnapora
left a comment
There was a problem hiding this comment.
I don't see anything that looks dangerous here (at least, nothing that's not lampshaded with "dangerouslyDoTheThing" naming 👍 ), and I like the explicit naming for the different types of bypass.
I'm not super crazy about the env file rewriter script... but I'm guessing that we need it in order to allow miniflare to use the bindings set in CI? That seems like a reasonable justification, IMO.
It would also be rad to add a note to the dev docs / README about the bypass modes - @gobengo maybe you could grab that as a follow up when you're back from dweb camp? I don't think we need to block on it, but it seems worth a mention. I left a couple other non-blocking suggestions if you have time to grab.
| @@ -1,3 +1,5 @@ | |||
| import { magicTestModeIsEnabledFromEnv, maybeJsonParseable } from './utils/env.js' | |||
|
|
|||
| export const createMagicTestTokenBypass = ( | |||
There was a problem hiding this comment.
If we can remove the export here and just export the concrete value magicLinkBypassForUnitTestingWithTestToken, that seems a bit cleaner. But if you need to export this for testing, that's okay by me...
Co-authored-by: Yusef Napora <yusef@napora.org>
|
status: I believe checks are green except for GITHUB_TOKEN rate limits |
| assert.equal(fn({ | ||
| NEXT_PUBLIC_MAGIC_TESTMODE_ENABLED: 'not-json-parseable' | ||
| }), true) |
There was a problem hiding this comment.
@gobengo having anything truth that isn't 'false' or '0' mean true seems like a foot gun. Please can we have exactly 1 valid way to enable test mode:
NEXT_PUBLIC_MAGIC_TESTMODE_ENABLED === 'true'
Motivation
What
playwright-report(html) to ci artifacts. this is useful to debug failed e2e test runs (with screenshots, console, network recorded!)apirunning anddbwith loaded schema