When a commit arrives that includes changes from A and B, or several commits arrive in very short order, both A and B will be published to the build queue. The snapshot dependency will trigger also a build from A, but since checkout rules exclude the commit from being relevant for A, as long as your dependency is configured to reuse builds when a suitable one is available, no new build will be produced and the last one will be reused, being able to simply run B. When a commit just for B arrives, the trigger on B will trigger it. When a commit just for A arrives, the trigger on A will trigger it, build, do everything, publish the artifact With the combination of the snapshot dependency and checkout rules, you would have the following scenario: For this situation, we would recommend setting B to have a snapshot dependency on A. Even if the artifacts do not come through TeamCity, and they are pulled from npm, there is a dependency in that you need A to run before B. Once you have this set up, it seems clear that B has a dependency on A in the example you posted.
Teamcity checkout rules code#
By completely removing projects from the build configurations, TeamCity can safely track which code is used by each build configuration, even if they share the same VCS Root. While filtering at the trigger level works for only triggering under certain conditions, if all your projects are independent from each other, can be built without reusing parts of the code from the others, we would start by recommending checkout rules instead of filters. What is the correct way to handle this scenario? (Note: in reality our system has more than 2 packages, but our problem is easiest explained in this stripped down scenario) 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 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. So packageB depends on packageA through its usage of packageA from the NPM registry. So each build configuration does a build, then publishes the built package to an NPM registry. and +:/packages/packageA, to avoid triggering when pacakgeB is changed)Īs 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. 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:. We have one build configuration per package. We have a git repository containing folders for different npm packages (monorepo).
0 kommentar(er)
