Storacha-branded validation flow #417
Conversation
|
Lint errors, please hold… |
View stack outputs
|
|
@alanshaw Not sure what's failing here. It should be unrelated. Are these tests a bit flaky, or did I bump something? |
.env.tpl
Outdated
| @@ -2,7 +2,8 @@ | |||
|
|
|||
| # uncomment to try out deploying the w3up api under a custom domain. | |||
| # the value should match a hosted zone configured in route53 that your aws account has access to. | |||
| # HOSTED_ZONE=up.dag.haus | |||
| # HOSTED_ZONE=up.web3.storage | |||
| # HOSTED_ZONE_STORACHA=up.storacha.network | |||
There was a problem hiding this comment.
Suggestion, make HOSTED_ZONE a CSV and map over the values. This would work for 1 domain or 2 or more.
The BRANDING env var could just be the domain.
Then we don't have implementation specific env vars and we don't add a new one!
There was a problem hiding this comment.
Do we actually want to support multiple domains? I envisioned this as something very temporary. Note that we have forking code paths for the emails and Preact pages. I don't think we actually want something like that indefinitely, just long enough to cover the launch of Storacha. What's in this PR seemed to me like the easiest thing to tear out later. Making HOSTED_ZONE plural is a bunch of logic if we don't actually want to keep it for long.
There was a problem hiding this comment.
Do we actually want to support multiple domains? I envisioned this as something very temporary.
I don't know for sure. In the past we've wanted to theme nft.storage emails, and we literally want this now. I don't see a lot of harm in retaining the logic. I find that temporary becomes permanent more often than I expect.
Note that we have forking code paths for the emails and Preact pages. I don't think we actually want something like that indefinitely, just long enough to cover the launch of Storacha. What's in this PR seemed to me like the easiest thing to tear out later.
I think I also suggested the forking could instead just be a keyed map of config (or at least I meant to). It would be quicker to not tear this out later and just reconfigure...
Making
HOSTED_ZONEplural is a bunch of logic if we don't actually want to keep it for long.
I guess yes, but I feel like pulling this out vs a plural HOSTED_ZONE would be approximately the same effort.
stacks/upload-api-stack.js
Outdated
| const customDomainStoracha = getCustomDomain( | ||
| stack.stage, | ||
| process.env.HOSTED_ZONE_STORACHA | ||
| ) |
There was a problem hiding this comment.
const customDomains = process.env.HOSTED_ZONE.split(',').map(domain => getCustomDomain(stack.stage, domain))| action_url: opts.url, | ||
| environment_name: this.environment, | ||
| }, | ||
| } |
There was a problem hiding this comment.
Config object keyed on the hostname?
There was a problem hiding this comment.
I'd prefer to do it this way at two, so it defaults more easily. My strategy here was to always default to the new branding if an unknown value is set. We could throw and blow up the function, but I'm not sure that's worth it here.
If we ever extend this to three, I'm all for it, and it's a pretty easy, local change at that point.
|
@alanshaw Rereview? WDYT? |
|
@hannahhoward Also, you're right that there are references to Notably, there's one As for reading from |
|
@Peeja for the filecoin and roundabout stacks, these are entirely API services with no direct interaction with the client. Honestly, they should probably all be on the storacha.network domain, but for now we can just avoid any change and use HOSTED_ZONES.split(",")[0] |
currently, seed.run fails 90%+ of the time because of the Filecoin test. until we have a more reliable way to test the filecoin flow, the PR disables it. the inserted comment suggests a few solutions -- either spinning up custom infra for w3filecoin pipeline on each pr to get more reliable results, or mocking out the pipeline
hannahhoward
force-pushed
the
storacha-emails
branch
from
0c3a2bd
to
194c0af
Compare
Stack outputs updated
|
These weren't failing locally with `npm run lint` for some reason? But they did fail with `npm exec eslint upload-api/test/helpers/validate-email-server.js`. In any case, they're fair complaints.
TS doesn't let you use the broad function signature to call the function, only the overloads. If the broad signature needs to be used, it needs its own explicit overload.
This makes type checks and linting easier, and it's generally a more cohesive solution.
Peeja
force-pushed
the
storacha-emails
branch
from
194c0af
to
6b2fb9f
Compare
Before Merge:
HOSTED_ZONES(plural) onprod.With
NEXT_PUBLIC_W3UP_SERVICE_URL=https://petra.up.storacha.networkin my localconsole:Then…
And success!
Or, failure.
Note that that error message is a dummy message in the test harness, not something real. Also, I see to have bumped something that made the Stripe section always appear. Previously, staging/prod was set not to show it by not providing the right env vars. I'm not sure why that changed, and whether we want it to.
Closes storacha/project-tracking#119