Improved change tracking for Git repositories for new branches, and when last built commit is abandoned.

From what I can tell the way TeamCity tracks changes for a Git repo from build to build is to look at the last build commit and then look for commits since then.  However, if a new commit comes in that rebases things upon an earlier commit, thus removing that last recorded commit from the chain, this logic falls apart.

In these situations, and in the situations of a brand new branch, this seems to result in it grabbing some unknown quantity of commits back in the history, something like 6 weeks worth in the project I'm looking at, or around 150 commits. This leads to,

  1. Confusing to read what has changed in a recent build.
  2. Hard to tell what changes might have broken things and resulting in excess emails about broken builds to users unrelated to it.
  3. Jira Plugin assigns the build to a lot more issues because it's looking at this extended history of changes that aren't really related to this build.


Could this logic for Git be updated to somehow figure the common ancestor commit and use that as the "last built commit"

For a brand new branch it's fairly simple, with the merge-base --fork-point option being able to give the commit the branch was initially created from.  I think for a new branch the list of changes made since the branch was created will be the most relevant.
git merge-base --fork-point <branch>

For a rebased build, you can run merge-base from the last known commit and the new latest commit.  Then use that as the new "last built commit". Unfortunately if the  Git server has pruned the abandoned commit and the TeamCity server no  long has a cached copy that includes it, then this isn't an option. Instead could store a list of the recent commits so that in the  majority of cases, it can still determine a more useful list of changes. Worst case, reverting to the last commit built from a prior build, or back to the fork-point for the branch would still be preferable over current behavior.

3 comments

Hi Jody,

at the moment there is no option to use a custom previous build revision like you described. TeamCity always computes changes in the same way: it takes previously started builds in the same or default branch, marks commits reachable from these builds as uninteresting, all commits reachable from newly started build which are not reachable from previous builds are shown in the build.

We have a request describing a problem with a newly created branch https://youtrack.jetbrains.com/issue/TW-33533, please watch it. There are cases though when one might want to see commits included in the default branch as described in the comments to the issue.

A workaround for the new branch is to run a build in the default branch on the commit from which branch will be created, in this case all commits below this fork-point won't be included in the build in new branch. You can use a similar workaround for the rebase: run a build on a commit 'C' on top of which you are going to rebase in the default branch, after that changes in the rebased branch won't include commits below 'C'.

Hope it helps.

1

Thanks that info helps greatly.  I'll check if there was no builds from the default branch in the cases I was looking at.

> it takes previously started builds in the same or default branch, marks commits reachable from these builds as uninteresting, all commits reachable from newly started build which are not reachable from previous builds are shown in the build.

This however I didn't observe as being entirely true.  There were 2 builds in one branch, the first was from a commit that got abandoned due to a rebase, and was the first build of that branch. I'm unsure if there was a build from the default branch for reference or not. The second build was based on a rebase from about 5 changes up. Both listed ~150 commits, however there was a large amount of overlap in those changes between the first and second build, there was only really about 6 new changes for the second build vs. the first, yet TeamCity still listed the huge history of changes.

Currently we're not clearing out build history at all, only artifacts and in this case the builds were hours apart anyways.

0

Hi Jody,

you are right. I wasn't precise enough. TeamCity traverse graph of commits and when it finds a commit C on which there was a build in the same or default branch, then it marks all commits reachable from C as uninteresting and doesn't show them in UI. In your case there is no path from rebased commit in second build to the old abandoned commit, that's why TeamCity doesn't find it while traversing a commit graph and show commits reachable from it in UI.

0

Please sign in to leave a comment.