Can we configure the max length of the checkout rules in a gradle based spring configuration?
We recently found the following warn message in our TC logs (see [1]) - it's concerning the gradle based composite build of our product that uses the combined checkoutRules of the sub projects. To my understanding this means that potentially the overall status of our product in TC might not be reflected correctly as it might not pick up some of the sub projects failing (see [2]).
Are these 2000 characters configurable somewhere?
[1]
```
[2020-06-08 10:05:44,870] WARN [ild chains changes collector 3] - erSide.impl.BuildPromotionImpl - The checkout rules in build configuration "product / product" are too long and will be truncated to 2000 characters. Rules before truncating:
```
[2]
```
- composite build (green) // as the checkout rule of sub build 3 gets truncated
- sub build 1 (green)
- sub build 2 (green)
- sub build 3 (red)
```
Please sign in to leave a comment.
Hi Ronald,
Unfortunately, the 2000 characters limit for checkout rules is not configurable - it is a hardcoded value. But maybe if you provide us with more details about your setup, we will be able to suggest a workaround.
It's not clear to me why you need combined checkout rules from three sub builds in your composite build (and also how do you assemble them, do you use dep parameters for that?). It's also not clear to me what you mean by "gradle based composite build".Composite builds can not have any build steps. Their purpose is to aggregate results from the builds they depend on. Could you please elaborate on the above?
Please also attach screenshots of:
As for the composite build status: it always picks any problems from dependent builds and should become red as soon as any build it depends on goes red. So I can hardly imagine a situation where a composite build is green, while some of the dependencies are red. In your example, I would expect the composite build to be red with something like "Build chain finished (success: 2, failed: 1)" in its status. Could you please share with us full build logs downloaded from the UI displaying the problem? You can use our uploads service to share the logs with us.
"gradle based composite build" was wrong wording, I will try to additionally explain our setup.
Our setup looks like the following:
We have separate git-repos for each of our products. Each product contains multiple services (in subfolders).
Therefore, in TeamCity, we have 1 project per product. Each of this products contain a composite-build (and 2 anddtional build steps on top level). The product-project contains several sub-projects, one for each service of the product. This service-projects contain a composite-build and multiple other build steps.
The composite-builds of the services provide some metadata-files. Those metadata-files are combined an a product-level-build-step, and then again provided via the product-composite-build.
We want the product-composite-build to run whenever any build of the product is run (to get the latest metadata file). Therefore, the product-composite-build contains all the checkout-rules from all sub-builds.
With the restriction of 2000 chars, it might happen, that the services are built correctly (since they contain only an handful of checkout rules), but the product composite-build is not triggered, if some checkout rules are ignored. Or am I wrong here?
Am I right to assume that the reason for all the checkout rules to be aggregated in your composite builds is that a VCS Trigger is used to trigger them, and in case some checkout rules are lost, the build may not trigger in the end.
Since you want composite builds to trigger whenever its certain underlying builds finish, maybe a Finish Build Trigger can solve this task better since the composite builds themselves only aggregate results and do not even checkout anything?
Yes, your assumption nailed it, this is exactly the reason why we did that.
I didn't know about the `Finish Build Trigger`. It sounds interesting and might solve our problem.
What exactly does the `Trigger after successful build only` do?
If this is checked, the build will simply not be triggered, right?
if this is not checked: Will the composite build fail if a sub-build fails? Or will it just do it's stuff and get green? Or ist this just what I define in the dependency rules (like fail if snapshot dependency fails)?
With `Trigger after successful build only` enabled, the composite build will only trigger if a sub-build finished successfully. Otherwise, should a sub-build fail, the composite build will not be triggered at all.
If this setting is disabled, when an underlying build fails, the composite build will also be red, and it will aggregate all the problems of the underlying build(s). For example, if an underlying build failed due to a couple of failed tests, the composite build will a corresponding record. The below screenshot displays the composite build overview page from the beforementioned example.
Hey, I just wanted to give you a quick update. We are going to extend the 2000 limit for checkout rules up to 16000 in TeamCity 2020.2.
The warnings you received are harmless if you don't use a multinode setup. Your server will take the information from the settings XML file where it is complete. The warnings indicate that the server will truncate the checkout rules before storing them into the database. This is because, currently, the field where they are stored is limited to 2000 characters.
If you use a multinode setup, you may be affected by https://youtrack.jetbrains.com/issue/TW-66593, because the secondary node in certain rare cases may rely on the database.
The finish build trigger is probably the best solution for your case anyway, but I just wanted to give you an update.