Can I set up configs so they are retrieved from the server if collecting changes from the VCS root fails?

Hi Chris, when you set up synchronisation in Versioned settings for a project, settings are automatically updated from the VCS with a polling interval configured for that Particular VCS in its settings. And there's a separate section which settings should starting builds use:

When set to "use settings from VCS" every starting build will try to pull an update from VCS prior to start. This might be not an optimal solution if your connection to the remote is unstable. But if you select "use current settings by default", builds will start with the last settings, successfully retrieved from the VCS. There will also be an option to run a build with settings from VCS via run custom build dialog.

By tweaking polling interval parameter in VCS Root settings you can control how often your settings should be updated, and by setting "use current settings by default" you're ensuring that your builds are always using working settings.

About those connectivity issues with github you mentioned: does it happen often? Are you using GHE or github.com? Is it all repos are unavailable during the issue or just the one with versioned settings?

Hmm, so with "use current settings by default" if I set the polling frequency to 10 minutes in the VCS root, it will try to update  the config on the server every 10 minutes. And if it fails to retrieve it will still use the old settings. This sounds like what I want.

As for my connection problems with github, I'm using github enterprise.

This was the most serious instance. That occurred once, and I think I fixed it by forcing a clean checkout. But that did cause multiple runs to fail.
Finalize build settings
[timestamp][Finalize build settings] Retrieve settings, revision: rev_uuid
[timestamp][Retrieve settings, revision: rev_uuid] Load project model
[timestamp][Retrieve settings, revision: rev_uuid] Read build settings from revision rev_uuid
[timestamp][Read build settings from revision rev_uuid] Failed to load build configuration settings from VCS: build configuration config is not found, use current settings from TeamCity server


This is a more common error:
Commit *hash* made from UI is not found in VCS, skip updating settings to revision *rev*
I sometimes get that when trying to manually load changes I made to the config. I can fix this by trying to reload the commit, or making another commit and then manually loading it. The weird thing is that when I look in the commit log on github I can always see the missing commit. It seems to be related to me making changes in the web ui, then making related changes in git and deleting the patch.

Here's an example:

Commit *vcs_change* made from UI is not found in VCS, skip updating settings to revision *revert*

Changes from VCS are applied to project settings, last change 'deleted empty line to fix error loading config in TC', revision *del_rev*

I changed to "use current settings by default". TC made a commit to my repo changing 100+ files. I didn't like this so I reverted it. When I tried manually applying the change I got the first error, three times. Making another commit had worked previously so I committed deleting an empty line. I got the same type of error message when I tried to manually load. But on the hour when github was polled for changes the latest commit was loaded. So I'm not sure why it was not able to find that commit.

I'm still using "use current settings by default". It doesn't look like versioned settings are saved in VCS, so reverting the commit did not change that.

Hi Chris, could you please elaborate a bit on how exactly you reverted the change made by TC (the one with 100+ changes)? What actions you performed: did you amend commit history, or did you use revert? The reason I'm asking is that I would like to try to reproduce your issue.

I just did git revert on the last commit in my repo.

But my config was highly modified. I have a few jobs that are almost completely the same. There's 4 or 5 subprojects, and each subproject has several build configurations. But the only difference between the jobs might be the branch in VCS, the schedule, or some other minor detail. I ended up refactoring the config so that loading a project is done by instantiating a new object with specific parameters. 99.9% of the code is in shared class and function definitions. Since I wanted the shared code in the same repo I created a parent project for the VCS root with the actual projects as subprojects. So nothing really matches up with the autogenerated kotlin config that TC creates, and loading VCS changes impacts multiple projects. 100+ file changes kind of makes sense.

Hi Chris, we don't save "when build start" setting in Kotlin configs (it's only stored in VCS if you have XML as versioned format) which means that if there were no other changes across the project, TC shouldn't have generated a commit in the first place. 

I tried to replicate the issue with loading settings from UI via clicking "Load project settings from VCS..." button after git-revert commit, but had no luck - TC successfully loaded the settings.

As a side note, when making changes from the UI, do you apply the patches TC generates to you project settings file? I suspect this 100+ changes commit could've been related to changes done from the UI and not reflected in settings file. Generally, it is advised to change project settings by modifying Kotlin DSL scripts themselves, but if you make a change from the UI, you should then apply a generated patch.