Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Docs: Netlify Deploy Should Be Through CLI, Not Website #2347

Merged
merged 4 commits into from
Dec 2, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
76 changes: 76 additions & 0 deletions web/docs/advanced/deployment/manually.md
Original file line number Diff line number Diff line change
Expand Up @@ -265,10 +265,86 @@ netlify deploy --prod

That is it! Your client should be live at `https://<app-name>.netlify.app` ✨

:::caution Redirecting URLs toward `index.html`
If you follow the instructions above, Netlify will use `netlify.toml` file that Wasp generates by default in `.wasp/build/web-app/`. This will correctly configure Netlify to redirect URLs toward `index.html`, which is important since Wasp is SPA.

If you instead use another method of deployment to Netlify, e.g. do it via CI, make sure that Netlify picks up that `netlify.toml` file, or configure URL redirecting yourself manually on Netlify.

It is recommended to deploy through the Netlify CLI in Github Actions. The first deploy can be through the website or manually to get a `NETLIFY_SITE_ID`, the following deploys can then be automatic.
:::

:::note
Make sure you set this URL as the `WASP_WEB_CLIENT_URL` environment variable in your server hosting environment (e.g., Fly.io or Heroku).
:::

### Deploying through Github Actions
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@infomiho I just merged this PR by a contributor. They made it clear that if deploying on Netlify, we need redirectin to be correctly set (either manually or using our netlify.toml).

They also added this section though, which shows how to exactly do it via Github Action. I approved it and merged, but I do wonder if this is too much for this part of the docs, are we going too far / doing too much here. Since you are now redesigning deployment docs I wanted to hear what you think. Maybe we will have a specific Github Actions section and this will be better explained there directly, instead of here under Netlify? Should we matbe (re)move this part?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Martinsos @infomiho Just wanted to hear your opinion on something similar: I am interested in writing documentation to deploy OpenSaaS on AWS (either EC2 or Lightsail), probably also including GitHub Actions to handle CI/CD.

I imagine I will briefly describe the peculiarities related to AWS, but maybe the GitHub Actions code is a bit too much? If that is the case I can put the detailed code that works with a particular version of OpenSaaS into a separate blog post, and only cover the general steps in the docs.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Bojun-Feng btw, @infomiho is on the conference from tomorrow so it might take him a bit longer to respond to this, but he should get to it the next week latest.

As for your question: Ok nice, that would be cool, the docs for AWS! Btw why OpenSaas, why not Wasp? I don't think there is anything OpenSaas specific? Or is there?

I think you are right, Github Action might be too much, especially if it has a lot of stuff that is "general" and not specific to AWS. But as you said, that could be a blog post for example, you are right! Btw we also ahve this https://github.com/wasp-lang/learning-materials -> sometimes we put stuff like this there. Hard to say at the moment if blog post or this is better, @infomiho might have some good ideas.


To enable automatic deployment of the frontend whenever you push to the `main` branch, you can set up a GitHub Actions workflow. To do this, create a file in your repository at `.github/workflows/deploy.yaml`. Feel free to rename `deploy.yaml` as long as the file type is not changed.

Here’s an example configuration file to help you get started. This example workflow will trigger a deployment to Netlify whenever changes are pushed to the main branch.

<details>
<summary>Example Github Action (Updated for 0.15.0)</summary>

```
name: Deploy Client to Netlify

on:
push:
branches:
- main # Deploy on every push to the main branch

jobs:
deploy:
runs-on: ubuntu-latest

steps:
- name: Checkout Code
uses: actions/checkout@v2

- name: Setup Node.js
id: setup-node
uses: actions/setup-node@v4
with:
node-version: '20'

- name: Docker setup
uses: docker/setup-buildx-action@v3

- name: Install Wasp
run: curl -sSL https://get.wasp-lang.dev/installer.sh | sh -s -- -v 0.15.0 # Change to your Wasp version

- name: Wasp Build
run: cd ./app && wasp build

- name: Install dependencies and build Vite project
run: |
cd ./app/.wasp/build/web-app
npm install
REACT_APP_API_URL=${{ secrets.WASP_SERVER_URL }} npm run build

- name: Deploy to Netlify
run: |
cd ./app/.wasp/build/web-app
npm install -g netlify-cli
netlify deploy --prod --dir=build --auth=$NETLIFY_AUTH_TOKEN --site=$NETLIFY_SITE_ID

env:
NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
NETLIFY_SITE_ID: ${{ secrets.NETLIFY_SITE_ID }}
```
</details>

<details>
<summary>How do I get the Environment Variables?</summary>

- **`NETLIFY_AUTH_TOKEN` & `NETLIFY_SITE_ID`**: They can be configured through Netlify.

- **`WASP_SERVER_URL`**: This is the link that points to your backend and is generally only available after **deploying the backend**. This variable can be skipped when the backend is not functional or not deployed, but be aware that backend-dependent functionalities may be broken.

After obtaining the environment variables, you need to store these values securely in GitHub Secrets.
</details>

## Railway (server, client and database)

We will show how to deploy the client, the server, and provision a database on Railway.
Expand Down