Update Serverless deploy #805
Conversation
|
| Name | Link |
|---|---|
| 🔨 Latest commit | c24b64d |
|
@joconor is attempting to deploy a commit to the RedwoodJS Team on Vercel. A member of the Team first needs to authorize it. |
|
Deploy Test 1I used I attempted a local deployment, which was successful. I ran into this error on https://d3j2lmbogvczkg.cloudfront.net There were no fetch errors in the Network tab or developer console. More suspicious is that there was NO GraphQL fetch in the Network list. Old content from the cache! I re-ran from Chrome Incognito, using "empty cache and hard reload". The error I got: Never seen that before 😬 Deploy Test 2I used I attempted a local deployment, which was successful. Ran into the same error as above. This is suspicious to me (from the deploy console): So I did make a change to a component, manually deleted web and api /dist, and tried the deploy again. Same console output. Same results. I've updated the PR with my local changes. Not sure what to try next. Unfortunately, this isn't the first time I've had to chase my tail when it comes to this deployment... 🐶 |
There was a problem hiding this comment.
I'm ok to try this for testing. But to confirm we have CORS working, we'll need to be able to deploy this with the original setting.
|
Hey @thedavidprice give it another try. Note that previously the auth function was missing from api/serverless.yml. And there were no GraphQL fetches because the posts were pre-rendered |
|
@joconor I spent more hours on this today than I care to admit. It's closer, but not 100%. Take a look at my changes here: And the remaining issues here: Good news is that it's not CORS. That is resolved. Also, I found I was running into a problem similar to your redwood#5785 only it had to do with conflicts between local deploy env vars and GitHub Actions. I've resolved it now. And I'm suggesting we just stop using .env.production. I really can't put more time into this in the near term. But I'll do my best to respond if you're able to keep iterating. |
|
Hey @thedavidprice I'll definitely keep iterating on this. I'd love to have a stable 'base' while trying to create a new Serverless plugin geared specifically toward the needs of Redwood. Question though: If you stop using .env.production (where 'production' is replaced by whatever the value is for the |
How are you deploying (local, GitHub Action, etc.)? And are you checking all those separate .env files into the Repo (other than .env.default)? For the case where 1) deploying locally and 2) you're not sharing .env files (which best practices say you shouldn't be doing), then you'll just each use the .env file. Yes, it's on you to match the values with the deploy target, but this is what you're doing regardless (it might just be in one file instead of multiple). Note: this has nothing to do with setting the stage/context on Serverless, in the serverless.yml, or via the Serverless CLI. Whatever stage you've set via those three contexts, the redwood CLI will always pick up Note: there's a tool (and others like it) for sharing .env called https://www.dotenv.org (repo here https://github.com/dotenv-org/dotenv-vault) Lastly, after doing a bit more research, it's feeling more clear that in the Node ecosystem, it's not idiomatic to use the pattern |
Update Serverless Framework & serverless-lift plugin versions
Use supported wildcard for api/serverless.yml
allowedOriginsAdd extension to web/serverless.yml to address AWS change to new S3 bucket default permissions.