How to make the "changes" shown branch specific?

Hi,

TC shows the changes that a build run includes, but it seems to do so indepently of the branches.

For instance, if I commit a change "C" in git, push it to master, and start a build,it will show "C" as change.
If I now push the same change to a feature branch, and start a build, TC won't show any change, presumably because the change was already known to TeamCity.
However, as a feature branch maintainer, I am interested to see what changes on my branch have been performed between 2 builds, and I want to see "C" as change for the last run on the feature branch.
Can TC be configured this way?

Cheers,
Olivier

4 comments
Comment actions Permalink

Hi,

Could you please write which git commands do you perform and attach your Change Log screenshot and what you expect it should be?

0
Comment actions Permalink

Hi,

No problem. On the developer client:

  • git push origin HEAD:master
  • git push origin HEAD:v1.0


"master" and "v1.0" have now the same content on the Git server.

Start a build in TeamCity, on "master", wait for it to finish.

On the developer client:

  • Make change
  • git commit -a -m "Bug fix"
  • git push origin HEAD:master


Now "master" and "v1.0" have diverged. TeamCity shows the new commit as pending change for master, which is correct.

Start a build in TeamCity on "master", wait for it to finish.
The "Changes" tab of the run shows the new commit, which is also correct.

On the developer client, push the very same commit to the v1.0 branch:

  • git push origin HEAD:v1.0


TeamCity does NOT show the new commit as pending change for v1.0.

Start the build in TeamCity, on "v1.0", wait for it to finish.

The "Changes" tab of the run does NOT show any commit, it's actually empty. It should show the new commit, since it is the difference between the last 2 runs on "v1.0"

I hope it's clearer now. Don't hesitate to tell if it's not.

0
Comment actions Permalink

Hi,

Thank you for clarification.
No, it is not possible to configure TeamCity to show the same changes twice for one build configuration. In this case we would suggest you to split your build configuration into two build configurations, and set up v1.0 as default branch for second build configuration.

0
Comment actions Permalink

Ok, thanks for the confirmation. The proposed solution is unfortunately not an option, since the branches are quite dynamic, and we have also already too many build configurations due to the diversity of our products.
I have therefore created a change request:
http://youtrack.jetbrains.com/issue/TW-37989

Cheers,
Olivier

0

Please sign in to leave a comment.