-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
ci(v3): test and lint v-next packages lazily #5564
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
7f164e9
to
0cc2836
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When a lockfile is modified we should run everything
I added pnpm lockfile handling in f8dc86c |
This PR is a subset of #5301 and, unlike the original, it targets the
v-next
branch.In this PR, I introduce the notion of deciding what packages to build in CI lazily. The intention is to build and test only these packages that were themselves modified or if one of their local dependencies (including transitive dependencies) were modified.
To achieve this, I added a script which parses the pnpm lockfile, builds up a map of local transitive depencies out of it, and outputs a filter that can be used directly with https://github.com/dorny/paths-filter (an action that filters a list of packages based on the modified paths).
The output of the script I added can be controlled with 2 environment variables:
PACKAGE_IGNORE
(to filter out the packages that we don't care about) andCOMMON_FILTERS
(to configure glob paths which modification should result in building all the packages).Example
In our script execution, we want to exclude the root package, the v2 packages and the example-project so we set
PACKAGE_IGNORE=["packages/", ".", "v-next/example-project"]
.We also want to ensure that modifying anything under
config-v-next
builds all of the packages so we setCOMMON_FILTERS=["config-v-next/**"]
.The output of our script (after parsing it with `yq`) would be:
Now, let's say we modify
v-next/hardhat-zod-utils/package.json
. If we, then, used the script output as the input to dorny/paths-filter action, we would learn that we should build only the following packages:hardhat
hardhat-zod-utils