Build Chain Suitable builds

Answered

Is it possible to adjust definition of Suitable builds for Build Chains to also look for builds in default branch?

We have:

  • monorepo with 6 apps
  • 6 build configurations building apps based on VCS Trigger rules to trigger builds only for certain folders.
  • Composite Package build that collect all artifacts, with Finish Build triggers for each of 6 projects
  • feature branches

If we do commit in one branch - then everything works as expected. Builds happen only for affected projects, so we don't waste build time to build same code projects.

We are working using small short lived feature branches with block to push on master. So if developer need to fix small bug in UI - he create new branch from master and push changes.

And that's where things go ugly. When pusing new branch - Team City rebuilds all 6 projects, cause 
Is there a way to workaround this?

4 comments
Comment actions Permalink

Hi Victor,

 

I'm not sure that I see such a setup would trigger every build. You seem to indicate having 6 different apps in a monorepo with different trigger rules to build each different one. Do the 6 different builds have shared code through the folders, or do the apps also live in separate folders within the same repo? If that was the case, if instead of Trigger rules you used checkout rules you would automatically exclude the build configurations from every change that does not match the checkout rules which should prevent new branches from triggering unrelated builds, even if with the current description it seems like a misconfiguration or a bug rather than an intended effect.

 

If that wouldn't work, please share the screenshots of 2 of the VCS Triggers and give us an example of a new branch push that would rebuild all projects, including which files were changed, so that we can try to replicate it on our end.

0
Comment actions Permalink

Hi, Denis, 

Thanks for answer,

I will try to explain our setup.

So lets say we have following structure:

- src\SharedLib 
- src\AndroidApp  - depends on SharedLib
- src\WebApp - depends on SharedLib
- src\ServiceApp - have no dependencies

In TC there is
- build projects to each app:
    1. AndroidAp with VCS triggers: "+:src\SharedLib\**", "+:src\AndroidApp\**"
    2. WebApp with VCS triggers "+:src\SharedLib\**", "+:src\WebApp\**"
    3. ServiceApp with single VCS trigger "+:src\ServiceApp"
- SharedLib has no own build configuration, it's small enough to be build by each app
- Composite build that depends on all APPs and collect artifacts from them, with uncheked Enforce and checked "do not run new builds if there is suitable one"


My main task now is to setup this configuration, so that when new changes pushed in new branch with change in WebApp there is no new builds for Android and Service app? Is it even possible, or Chain Builds assum that all dependands should be build from single branch?

I.e. is it possible to tell Composite build that if there is no builds in this branch, then search for suitable builds in <default> branch?
Do VCS triggers are taken into account when suitable build calculated? Or I should use Checkout Rules?

 

0
Comment actions Permalink

Hi Victor,

 

I'm afraid triggers will not be taken into account for suitability, checkout rules will. We have a pretty thorough description here: https://www.jetbrains.com/help/teamcity/snapshot-dependencies.html

 

With this in mind, simply moving the trigger rules to their respective checkout rules, should do the trick. Whenever a trigger is run, such as for dependencies, TeamCity checks whether the build has pending changes. If you just set the rules on the triggers, then pending changes will be present, and thus a new build will be required. If you set them as checkout rules, the pending changes will not be present, because checkout rules make the builds ignore those changes to the effect of the builds. The VCS Trigger is able to ignore pending changes through its own trigger rules, but other triggers (such as snapshot dependencies) will not take those into account, as those settings are trigger-specific.

 

If you are interested in collecting artifacts for every time a build triggers, you could also drop all vcs triggers from the intermediate builds, set the trigger on the composite build (enabling trigger on changes in snapshot dependencies) and that should automatically trigger everything as required, reuse as required, etc.

0
Comment actions Permalink

Thanks, Denis.

 

Checkout rules are quite tricy to use, but with some of degree of success I were able to create build chain that work for us

0

Please sign in to leave a comment.