ci: separate staging.yml for frontend and backend #1050
Conversation
There was a problem hiding this comment.
This change is seems okay, though I'm really not concerned about us re-deploying staging too often - it doesn't cost us anything, and brief staging outages are not a problem.
@Gocnak you should probably take a look at this as well.
| paths: | ||
| - "apps/backend/**" | ||
| - "apps/backend-e2e/**" |
There was a problem hiding this comment.
Changes to code in /libs can affect both front and backend, this should use paths-ignore, and ignore /apps/frontend* and /scripts.
| paths: | ||
| - "apps/frontend/**" | ||
| - "apps/frontend-e2e/**" |
|
That will run both actions if you change something that is outside of these directories, which should be fine. Updated as requested. |
|
Yeah. Staging deploys don't cost us anything and I'd much rather we run these jobs when not necessary, than fail to run them when we should. We could exclude other files, but I don't want a maintenence burden of updating the that list. |
|
Waiting for Nick to check this out, might take a bit, but this isn't high priority. |
Separate staging.yml to staging_frontend.yml and staging_backend.yml
This allows us to use the "paths" parameter, so that changes to the frontend only run the frontend action and changes to the backend only run the backend action instead of running both.
Screenshots (if applicable)
Checks
nx run db:create-migration <name>and committed the migration if I've made DB schema changesfeat: Add foo,chore: Update bar, etc...fixuped into my original commits