mozilla / dawg

Data Access Workgroups (DAWG) aggregates workgroup definition artifacts into an unified view.
https://protosaur.dev/dawg/
1 stars 1 forks source link

chore: CI jobs all use `/dawg` base route based on CI envvar #38

Closed corbanCloud closed 1 month ago

corbanCloud commented 1 month ago

CI and NPM scripts have been re-worked to simplify invocation in CI as it is in local dev. Playwright and Vite are now internally responsible for configuring themselves rather than the CI system or developer needing to add/pass in flags e.g. --base=/dawg/ to get correct builds/tests

When CI is set to true (as it always is in Circle CI) vite will run it's dev server, tests, and builds with the /dawg/ prefix, Playwright will set the base url for it's tests to include /dawg as well. To support this the playwright URL paths have been made "relative" by adding a leading . infront of them which creates some noise in the diffs.

This should prevent future issues where bugs are only present when running with a prefixed built, since all CI tests will be done with a prod like prefix

This also improves the DevX for debugging these issues as simply setting CI=true will cause a given NPM script to run locally as it would in CI w/o any additional configuration.

README.md has been updated to reflect the above changes

corbanCloud commented 1 month ago

Thats somewhat true, but if we wanted to do handle the prefix the right way from the go (had we known about it from day 0) we would have pretty much ended up here anyways.

Looking into the lint, if you got diffs it feels like it should have failed in CI ... 🤔

corbanCloud commented 1 month ago

ah ok, lint runs w/ fix so it doesnt exit w/ non-zero it just writes changes hence the diffs and lack of failure