chore: #27 land the CI workflow on main #37
Merged
+131
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What this does
Gets the CI workflow onto
main. It has been missing entirely.How that happened: PR #34 had base
feat/1-repo-toolingbecause it was stacked on #32. #32 mergedfeat/1-repo-toolingintomainat 17:11, then #34 merged intofeat/1-repo-toolingat 17:28. By then that branch was no longer feedingmain, so the workflow landed on a dead-end branch.mainhas only ever hadCODEOWNERSunder.github/.So every PR opened since then, including #33, #35 and #36, has had no CI at all. Worth knowing when you review those.
What is in the file
Unchanged from what #34 reviewed:
qualityon every PR and every push tomain:pnpm install --frozen-lockfile, thenformat:check,lint,typecheck,test,build, then a client bundle budget of 512 kB per JS chunk.deployon push tomainonly: builds and publishesclient/distto/var/www/html/project2, curls it to confirm it served, and restartscrate-apionly if that systemd unit exists. So it works today at M1 and still works in M2.Two fixes that came out of running it
1.
pull_requestno longer filters onbranches: [main]. A stacked PR like #34 targets a branch, so the filter silently produced zero workflow runs. I noticed only because my push produced no run at all. We stack PRs, so a branch filter is wrong here.2.
deployis pinned to[self-hosted, linux, x64, project2]. Rachel spotted that theproject2label was never used inruns-on. She was right.deploywrites to/var/www/html/project2and restartscrate-api, which only exist onit2810-19, so it must not land on a different machine if a second runner is ever added.qualitystays unpinned on purpose since it is a pure function of the tree.What was tested
it2810-19-project2, online):qualitygreen in 23s on run Project plan and git workflow #4.deploycorrectly reportsskippedon pull requests.mainwill rundeployand update the live site at http://it2810-19.idi.ntnu.no/project2.Closes
Closes #27.