Yarn Workspaces Follow Up

[leeyi45]

This PR is intended to fix the little teething issues here and there, especially with the CI:

• Incorrect docserver base path resulting in the styling and links being all wrong
• Sneaky bug in the github actions workflow that was throwing errors on certain packages (fixes Root package missing in topo order? #478)
• Devserver not being able to build the tabs that it needs to build
• The matrix jobs still trying to spin up a whole job just to stop execution when their corresponding package doesn't have changes
• The matrix jobs trying to execute even if there aren't any tabs, bundles or libraries that have changes
• Certain jobs not executing if the matrix jobs don't execute at all

[leeyi45]

At first glance, it does seem that the CI actions do work. At the time of writing when I only have minor changes in the docs server it isn't trying to run every other job

[RichDom2185]

Is the case where it is a lock file only change with no change to package.json (as it is the case with renovate dependency updates or running yarn upgrade-interactive) handled?

[leeyi45]

Is the case where it is a lock file only change with no change to package.json (as it is the case with renovate dependency updates or running yarn upgrade-interactive) handled?

I don't think so actually. If git doesn't detect any changes for that package it won't rerun anything for that package.

I'm not too familiar with renovate - is there a way to detect what changes it's trying to make?

[RichDom2185]

Is the case where it is a lock file only change with no change to package.json (as it is the case with renovate dependency updates or running yarn upgrade-interactive) handled?

I don't think so actually. If git doesn't detect any changes for that package it won't rerun anything for that package.

I'm not too familiar with renovate - is there a way to detect what changes it's trying to make?

The solution I have in mind actually works for any PR, which is just to git diff this brunch against the merge base, which exists as a GH action variable, and then based on the list of file names determine which bundle is it a part of.

Though it's true that yarn lock will always be affected on any dependency change (even if it's only used in a bundle) because we only have one lock file shared across the entire monorepo.

I guess, instead of building the dependency tree based on package JSON version numbers alone, we use those to check the actual resolved version based on the lock file and mark whichever bundles a lockfile change would cause the resolved version to be dirty from there

[leeyi45]

@RichDom2185 I had a go at trying to implement what you suggested, not sure if it has the intended effect (because it seems to consider everything as "dirty" right now)

[RichDom2185]

@RichDom2185 I had a go at trying to implement what you suggested, not sure if it has the intended effect (because it seems to consider everything as "dirty" right now)

I'll take a look, thanks!