VCS terminology and behavior questions

I am trying to provide support in TC like i have in other build systems, but the terminology is confusing me..

using git
the job will be externally triggered thru REST api request. passing parameters

each developer has their own private branch. they make chnages locally then push to the server side.
this triggers a build on this branch, MERGED with the upstream shared branch (integration)

I want to
define two branches to be extracted
integration
then the user branch (passed to the job as a parameter).
(this last part works)

I do NOT want TC to trigger any builds (aka NO vcs 'monitor' branch)

I want to use the Automatic merge function (I think)  to merge the user branch to the 'integration' branch    

both user and integration are specified in the VCS branch specification table
+:integration
+:$teamcity.build.branch%

how do I confirm that the two branches where loaded to the same file location on the build agent

the automatic merge fails, unable to locate branch 'integration'

12 comments
Comment actions Permalink

Hi Sam,

All branches are downloaded to the same location on agent. While it does not matter where the branch was downloaded. It should be just mentioned in Branch Spec. For git you should use +:refs/heads/integration. In Automerge feature the logical branch name should be used.

0
Comment actions Permalink

thanks.. using the automerge. It now works with the refs/heads specifier added..

I do NOT want job triggering..   I don't see a way to disable that

0
Comment actions Permalink

To prevent triggering on specific branch you can add Branch Filter to your VCS trigger, like this

+:*
-:logical branch name
0
Comment actions Permalink

thanks..   that sure is a hard one to notice.

now down to two more issues

1. altho I have an agent running and this is where the job runs, I still see 'server side checkout' in the job log.

[11:28:47]Updating sources: server side checkout
[11:28:47]Using vcs information from agent file: 102da0b47f468387.xml
[11:28:47]Building  incremental patch for VCS root: git@githome:/home/git/cacdf.git;  checkout rules: =>samd; revision:  1c6450c44f96b017691173ef96dc510f33bfc9c8 -->  1c6450c44f96b017691173ef96dc510f33bfc9c8
[11:28:47]Repository sources transferred
   the system architecure is
       tc is on 192.168.2.33 (aka buildserver) ubuntu 64 bit, java 7

       git is on 192.168.2.32 (aka githome)  ubuntu 64 bit, java 7
       agent is on 192.168.2.36 (no dns name)  fedora 14 64bit, java 7


2. Automatic  merge failed: Cannot find destination branch to merge into: no VCS  branch maps to the 'integration' logical branch name according to the  VCS root branch specification

a. the vcs specifies the default branch as origin/integration.. no matter what I type here it gets overlayed with 'origin/integration;

b. the branches to monitor is set to (no build triggering)
       -:integration
       -:%teamcity.build.branch%
vcs-root.jpg
c. then Automatic Merge settings are
watch builds in branches
       +:%teamcity.build.branch%
       +:integration
and
branch to merge into
           integration
amerge.jpg

0
Comment actions Permalink

1. There two type of checkout modes: server and agent side. In both modes sources are checked out on agent, but the checkout mechanism is different. For more details please read: http://confluence.jetbrains.com/display/TCD8/VCS+Checkout+Mode

2. All branches that are used in Auto Merge feature must be present in a repository and included into the Branch Specification (or mentioned as default).
    If you do not want to trigger builds then you should not create VCS trigger (in previous comment I wrote about trigger rules, not branch specification).
    Also do you really need to watch builds in integration branch in Auto Merge feature and hence merge from integration into intergration.

0
Comment actions Permalink

1. ok.. I do not see a way to force the server/agent checkout configuration..
    it makes no sense to move the code twice..  once to the server and then once to the build agent machine.

2. sorry, I do not understand the terminology
    there are three branches in the git repo
     master - not used
     integration - at revision 1c6450c44f96b017691173ef96dc510f33bfc9c8
     sam_d - at revision  1735732737eefc6022e5a782842a4e108242831b


I want to extract branch integration to the build agent disk (in the working directory)
then extract the changes or delta from the specified user branch (sam_d, passed as a parameter to the rest api request to start this job) over the top of the integration branch(default branch)
    prefer a local merge, which if successful will then build,

> All branches that are used in Auto Merge feature must be present in a repository and included into the Branch Specification (or mentioned as default).
correct, that is per the screen shots provided

and if THAT is successful, will automerge the user branch (sam_d) into the specified branch (integration)
-- automerge fails cause 'origin/integration' is not found, (the string in the default branch field in the vcs root, which chnages to this everytime I look at the vcs root definition)

>    If you do not want to trigger builds then you should not  create VCS trigger (in previous comment I wrote about trigger rules, not  branch specification).
I have no triggers defined.

> Also do you really need to watch builds in integration branch in Auto Merge feature and hence merge from integration into intergration

again, I have a terminonlogy problem..
we are specifying branches all over the place

default branch
branch specification (list)
automerge branches to watch (list)
automerge branch to merge to

there is no build 'in the integration branch'.. only in the temporarily merged integration+user branch combo

watch is a confusing word..
as watch implies a long time period.. and what I want is at the end of this running build I specifically started, if it is successful, then merge user branch back to integration (AT THE SCM server)
using the user branch revision and the then current integration branch revision (which COULD have changed while the build and unit tests were running on this build job.)

0
Comment actions Permalink

I am not getting the checkout behavior I expect, and automatic merge still fails.

if the 'default' branch is refs/heads/integration
and the branch space is set to
+:refs/heads/sam_d

on checkout I get the code from refs/head/integration only..

if I switch the 2 I get the code from refs/heads/sam_d, and not both

so, it appears the pre-build temp merge is not executing.

again I am trying to do a local merge
(assuming this is agent checkout)
teamcity.build.branch (newer branch) -> (into) (local copy of) integration (older branch)
run build


if succesful
automerge , actually update the  target branch

-------

secondarily
if I set the default branch to %teamcity.build.branch%, and save, and run I get the results as if it is the default branch
if I edit the vcs root again,
default branch is set to origin/integration, every single time, no matter what I do..

0
Comment actions Permalink

anybody have any suggestions?

0
Comment actions Permalink

Hi Sam,

Sorry for late reply.

1. There are pros and cons of both checkout methods. For more details please see http://stackoverflow.com/questions/1799309/server-side-checkout-vs-agent-side-checkout

2. There is no ability to perform local merge. When you start build on the branch only this branch is checked out to the working directory. It works "as designed".

So for example you run build on branch sam_d and have an auto merge build feature configured. If the build if successful then branch sam_d will be merged into integration branch in the repository (not locally).

You can create your own script to perform needed functionality.

Please the related blog post: http://blog.jetbrains.com/teamcity/2013/10/automatic-merge/

3. >if I set the default branch to %teamcity.build.branch%

The parameter teamcity.build.branch is predefined build parameter. When the build starts the branch name is added to teamcity.build.branch parameter, but it is not passed to the build itself. Seehttp://confluence.jetbrains.com/display/TCD8/Predefined+Build+Parameters#PredefinedBuildParameters-ConfigurationParameters.

You can use this property inside your build script or in auto merge future, but not in VCS root settings.

0
Comment actions Permalink

1. got it.. checkout mode is hidden.. shame that it appears to impact ALL vcs roots defined here..

this should be inside the vcs root

1a.  when set to agent checkout, I cannot use password, but I do not have access to the TC server, so I cannot select the key file for other authentication mechanisms.
     I am setting up the job from a windows machine web browser. the other two servers are linux, but I don't have admin access.

2. bummer..

3. the vcs config tool lets me select the %teamcity.build.branch% into the default branch field.

if I am building my own script, then I don't want the VCS to manage the branches.

0
Comment actions Permalink

1. We have the related issue https://youtrack.jetbrains.com/issue/TW-14796. Please watch/vote for it.

3. When you print % - all available parameters are shown.

If you use your own script to perform checkout and merge then you can select "Do not checkout automatically" VCS checkout mode.

If current TeamCity functionality does not meet your requirements, please feel free to create an issue or a feature request in our tracker.

0
Comment actions Permalink

thanks.. will follow the rfe..

appreciate the help.

Just trying to not disenfranchise our TC users as we build out our CI and CD architectures and tools.

Want to provide re-usable templates that implement the key features, so every team doesn't have to learn everything to leverage it..

0

Please sign in to leave a comment.