Updated CI/CD Tests #405
Updated CI/CD Tests #405
Conversation
| #push: | ||
| # branches: | ||
| # - main | ||
| pull_request: |
There was a problem hiding this comment.
What would be the motivation for running this on every pull request rather than on pushes to main?
Wouldn't this just be testing the configuration of the main branch and not the changes being introduced?
If we want to keep it as being triggered by pull requests can we only trigger it when files in src/website and .devcontainer are modified?
There was a problem hiding this comment.
From my understanding, running this on every PR would ensure that changes in the PR would not break the deployment before they are merged into the main branch, which would also provide another layer of testing to catch issues early. What do you think?
Also, good point. If we do want to keep it as being triggered by PR's, then it should only trigger when files in src/website and .devcontainer are modified. I will fix that
There was a problem hiding this comment.
Yeah sounds like a great idea to test out how changes deploy before actually deploying to the real site.
The main branch will be checked out on the VM, and not the development branch
I'm sorry that's totally wrong ^
Would the VM that this workflow deploys to be like a pre-production environment and not the actual web host?
If so, then I think keeping it as triggered by PRs makes sense, and maybe we can keep the push trigger as well and deploy to either the pre-production VM or the actual website host VM depending on the trigger event.
What do you think?
There was a problem hiding this comment.
Your idea sounds great, since the VM that the workflow deploys will not be the actual web host.
| git pull | ||
| touch src/website/.env.local # Adds a local environment file to VM to override env vars in .env.production | ||
| echo NEXT_PUBLIC_SERVER_HOST=http://${{ secrets.SSH_HOST }} >> src/website/.env.local | ||
| docker compose -f .devcontainer/docker-compose.yml -f .devcontainer/website/docker-compose.website.prod.yml up --force-recreate -d --build --remove-orphans |
There was a problem hiding this comment.
I don't see a verification that docker is installed on the VM prior to deploying to it. Which is fine, just wanted to clarify as you mentioned it resolved that issue
Description
Verification
Resources