Is there an options to disable "history builds"?

Hi,

I'm afraid that disabling history builds entirely is not an option. We have a description of what builds are considered "history builds" here: https://confluence.jetbrains.com/display/TCD10/History+Build. If builds are incorrectly being tagged as history, we would need to investigate that further.

According to your screenshots, branch4 has no changes pending on the VCS Root, which means that new builds are going to be considered history if the rest of the conditions are met.

This said, you mention issues with history builds and triggers. Are you using a finish build trigger? If yes, is there any reason for it over a snapshot dependency and triggering the later build? Are there actual changes that should have been applied there? As in new changes in the VCS Root attached that weren't picked up?

Hi,

Are you using a finish build trigger? If yes, is there any reason for it over a snapshot dependency and triggering the later build? 

We use snapshot dependencies. For example, Queue Lib depends on IOC Lib. 

IOC build configuration has custom checkout rules that will checks out the only folder with IOC Lib sources.

%Project.checkoutpath% = %ourprojects.rootfolder%\Source\branches\%teamcity.build.branch%\Project\Tools\%system.teamcity.buildConfName%

IOC doesnt has any snapshot dependencies.

Queue checkout rules almost the same except Checkout rule path: +:/Tools/Project.Queue => /

Queue has snapshot dependencies:

---------

Are there actual changes that should have been applied there? As in new changes in the VCS Root attached that weren't picked up?

Yes. Seems like VCS Root doesn't show changes if same sources were already built in another branch. (Or by some other reason) Seems like TeamCity tries to reuse older builds, from the 'master' branch and skips rebuilding of snapshots.

For example, I start some 'MyBuild' that has 2 snapshot dependencies on Logger and IOC. I expect that all snapshot dependencies will verify if anything has changed in the sources, then snapshot dependency will be rebuilt in the current branch, without using previous builds from master. (as we use %teamcity.build.branch% variable in the In the %Project.checkoutpath%)

Sometimes the "rebuild all snapshot dependencies transitively", manual re-running of all builds or adding new commits helps to achieve it.

Sometimes deleting the folder with sources on build serve helps too (because correct sources will be downloaded again an used for build).

----------

I'm afraid that disabling history builds entirely is not an option.

Maybe it's not needed in this case. Do you have any suggestions on setting up TeamCity for more aggressive detection of changes in the VCS Root? (To use lates sources of the current branch during the build).

Thanks.

Thanks a lot for the detailed explanation. As you say in the end, it's likely not needed to disable history builds. Indeed when TeamCity detects the same revision in different branches, if the revision has already been built, TeamCity will consider that it doesn't need to build it again and will mark it as history. If I'm not mistaken, the history builds you are seeing do indeed have the correct revisions, am I right?

If this is the case but you would still like to run the same revision in multiple branches, we have the internal property teamcity.vcsTrigger.runBuildOnSameRevisionInEveryBranch that can be set to true so that the same revision will be run in every branch anyway.

Could you try setting it up and seeing whether it does the job? If not, please report back and I'll try to figure out what the problem is.

Hi

If I'm not mistaken, the history builds you are seeing do indeed have the correct revisions, am I right?

Yes, I think so.

Could you try setting it up and seeing whether it does the job?

I've set this property to true. I'll monitor for one or two weeks if this resolves our build issues.

Thank you!

Hi Denis,

Our problem was resolved by setting teamcity.vcsTrigger.runBuildOnSameRevisionInEveryBranch to true.

Thank you!

Hi Denis,

We facing the history builds again.

Assume that dependencies graph

Lib1 -> Lib2 -> ... -> Service1

Lib1 -> Lib2 -> ... -> Service2

etc

Service1 and Service2 has Finish Build Trigger 

Changes to the Lib2 were made in December.

Changes to the Lib1 were made in April 

When Lib1 was changed in April, Lib2 has changed in April too (through Snapshot Dependencies). We expect that all builds will use April version of Lib2.

For some reason (we don't understand why) Lib2 was used as "History Build" and it took the build from December (#232), instead of the latest April build (#342)

See this screenshot:

Can you suggest how we can set-up TeamCity to always use the latest build (#342 in the example above) instead of the history build(#232)?

Thanks.

Hi All,

Has anyone ideas how to set-up TeamCity to always use the latest build (#342) instead of the history build(#232)? (See the previous comment for more info)

Thanks.

Hi All,

Can anyone look at my previous comments and help to resolve history-build-related problems?

Thanks.

Hello Nikolai,

There is no option like "always use the latest build" as what build should be used is determined using a number of factors.

The most important question here is how exactly the "wrong" build is triggered.
Let's try to collect all the necessary details for a single case of the issue reproducing so that we can figure out why the issue occurs and then suggest corresponding measures.
It might be still worth waiting for TeamCity 2018.1 release (due in several weeks) and making sure the issue is still actual there as there were some fixes which might be related.

Anyway, as for the collecting case details, we will most probbaly need:

• Details of the wrong build with it's "Triggered by" (e.g. screenshots of the build's Overview tab), build's revisions (on the Changes tab), snapshot dependencies (entire chain) form the Dependencies tab, build log (downloadable form the Build Log tab, most importantly the verbose logging until the actual build start on the agent). The same details for the dependency build, if wrong build is used.
• Details on what you consider is wrong and the expected values.
• Most probbaly we will need the details of the checkout rules configuration for the build configurations in question and also details of the related triggers. Also, any "teamcity.*" configuration parameters set for the build configurations
• If the revisions are wrong, then we will need Change Log of the build configuration with the builds and commit graph visible as well as the revisions as seen in the Git client with the revisions (actual.expected) highlighted and the graph between them. If you use checkout rules, then we will also need files visible on the Change Log and files in the Git commit graph
• Please also collect build history between the builds for the using and used build configurations.

Hi Yegor,

Sorry, I've lost track on this topic during vacation and didn't respond in time.

>The most important question here is how exactly the "wrong" build is triggered.

We've replaced the "Finish Build Triggers" to "Snapshot Dependencies" and it has resolved the problem for us. Now we always get the correct artifacts after build and don't face "history builds" anymore.

The only downside - on the master branch after changing one of the core libs, we have to click "run" on each dependent build configuration. Other branches have VCS Trigger.

Thanks

May be released this function at latest version?

Hi,

no, there will be no option to disable history builds entirely in the next release. If you would like to see this feature implemented, please vote in the related feature request: https://youtrack.jetbrains.com/issue/TW-18651

Is there any way from the build script to detect a "history" build?  I know there is a "BUILD_IS_PERSONAL" parameter defined when running a personal build.  I need something similar for a "history" build.

You can make a REST request to the builds endpoint and the build will have a history="true" attribute that you can check for that.

Denis, Can you provide more detail?   I know nothing about the  TeamCity's  REST API.

There is a description of the builds endpoint here: https://www.jetbrains.com/help/teamcity/rest-api.html#RESTAPI-BuildRequests

If you navigate to the top of the same page you can see the basics of connecting to the server via the api, such as paths and authentication. I'm afraid there is no parameter or variable that contains the history build flag otherwise, so the REST API is the only current option.