Deploy Previews for Pull Requests on Google Cloud Run #841
Conversation
|
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/metafam/the-game/JBELuQ4FFXxoTDs8Xrop8hwjwsz2 |
|
(close and reopen just to trigger a redeploy btw) |
|
the deployment was finally successful! |
polimyl
added
the
ready-for-review
This is slightly concerning; how close do we think this is to the one built / deployed by Vercel?
Yes that would be amazing. It is takes FORRRRREVER to build the backend because it's enormous. Fixing this would really really improve our productivity
This is actually pretty important, especially with our rebase git workflow. Whenever we rebase we force-push the changes, which means that PRs are often updated. Separate PR is totally fine |
|
Oh, and whose google cloud account is this being deployed to? What is the pricing for this sort of usage? |
| @@ -2,8 +2,9 @@ FROM node:12 as base | |||
| WORKDIR /usr/src/app | |||
|
|
|||
| ARG GRAPHQL_HOST | |||
| ARG GRAPHQL_DOMAIN=onrender.com | |||
There was a problem hiding this comment.
I assume we don't need to add this env variable to our render.com account ?
There was a problem hiding this comment.
add this env variable to our render.com account ?
What exactly do you mean by that?
If you mean actually setting it on build then no, since it defaults to "onrender.com", which it also was before this change.
I couldn't find a Dockerfile for the Frontend in this repository. And since Cloud Run might be cheaper than Vercel from what I have been told and I couldn't figure out how to make Vercel delay the building of the Frontend until the Backend is deployed and then use that, I also build and deploy the Frontend so we can in the future stop using Vercel for previews (dysbulic said he has no issue with me doing that).
Just wanted to get a working version out as early as possible so everything gets battle tested while I'm working on the rest
@dysbulic gave me access to a Google org. It looks like the main MetaGame one since the metagame.wtf domain seems to have been registered by it. He might be able give you some more details on it.
The actual hosting part will probably fall well into the free tier. I also push the built Docker images to a google registry, which looking at the huge size of the images might cost a bit. Not sure how much exactly since I'll try to optimize them later on. If it costs too much we could also easily push them to Docker Hub instead since they will be completely free there. |
|
Dope! Nice work. I'll rebase my other branch and hopefully get a working deployment 💪 |
|
Successfully undeployed the Preview of this Pull Request |
polimyl
removed
the
ready-for-review
Closes #823 (also expands a bit on it)
This pull requests adds two github actions workflows: gcp-deploy and gcp-undeploy.
gcp-deploy builds Hasura, Backend and Frontend as Docker containers, pushes them to the Google Registry, creates a new user and databse in Postgres and deploys those containers to Cloud Run. It does so whenever a pull request gets opened or reopened.
gcp-undeploy deletes the deployed Cloud Run instances and the Postgres database and user. It does so whenever a pull request gets closed.
This pull request also adds a Dockerfile for the Frontend since Cloud Run only accepts Docker containers and the Frontend didn't have one yet. It's basically just a copy of the one for the Backend.
Both the Frontend and Backend Dockerfiles are pretty unoptimized atm. The built containers have a size of nearly 1GB, which is huge (the Hasura container has a size of less than 70MB for reference). This could use some work in the future (I'll create an issue on that when this PR gets merged).
I have also just noticed that there probably needs to be some way to redeploy a pull request when changes have been made to it that's not closing and reopening the pull request. This would probably be something for a separate pull request once this one is merged.