We have a git repository containing folders for different npm packages (monorepo).
The folder structure is:
packageB depends on packageA
We have one build configuration per package. Each build config uses the same VCS root, AND (to avoid unnecessary builds) each has a VCS trigger rule which excludes all folders except their own (so the trigger rules for packageA are: -:. and +:/packages/packageA, to avoid triggering when pacakgeB is changed)
So far so good.
As I mentioned before, there are dependencies between the packages BUT, these dependencies are not through source, but through an NPM registry, to which each build configuration publishes. So each build configuration does a build, then publishes the built package to an NPM registry.
So packageB depends on packageA through its usage of packageA from the NPM registry.
The problem: if there is a commit with changes to BOTH the source of packageA AND packageB (so there are modified files in both packages/packagesA and packages/packagesB), then both configurations are triggered simultaneously.
This leads to the build of packageB to fail, since it needs the updated version of packageA from the NPM registry, which is only ready after the build config of packageA has run to an end, and the new packageA has been published to the NPM registry
(Note: in reality our system has more than 2 packages, but our problem is easiest explained in this stripped down scenario)
What is the correct way to handle this scenario?