Always pending, never builds

I just installed TeamCity, and configured a Java hello world project.

I commited a small change to Subversion and saw the TeamCity project go to "Pending (1)".  Very cool, this is looking good.

Then, minutes later, I'm still at "Pending (1)".  Ah, silly me; I forgot the build trigger.  OK, I added the build trigger for each check-in.

Then, minutes later, I'm still at "Pending (1).  TeamCity knows of the VCS checkin, and I said to build on checkins.  But, nothing.

I tried:

  • Disable and re-enable the build trigger
  • Stoped and started the build agent and server


I did eventually get it to build; but only by committing another change to the source code.  That is not the behavior I expected.  I can't remember any other CI product behaving like this.  I must be missing something here.


Environment:
TeamCity 7.1.4 (build 24331)
Windows Server 2003 - Standard Edition - SP2
JDK 1.6.0 31
Hello World Project

  • Ant build configuration
  • Subversion VCS
  • (*) Ignore externals
  • Checking interval (uses global server setting of 60 seconds)
  • VCS checkout mode: automatically on server
  • Build trigger on VCS check


Thank you for your time,
Marshall

6 comments
Comment actions Permalink

>I did eventually get it to build; but only by committing another change to the source code.  That is not the behavior I expected.
I was surprised too.

>I can't remember any other CI product behaving like this.
I haven't used others, but a related snafu for me is that if turn off the jobs, then any commit during 'off' cannot be rerun. Nor can I build for a revision before I started TC as a service. (I'd have to check for exact steps, possibly I'm misspeaking a bit.) Can other CI do that?

0
Comment actions Permalink

I've done minimum testing on: Bamboo, CruseControl, Go, and Jenkins.

I'm fairly certain I've seen the desired behavior on all of them.  Though, to be sure, I'd have to re-run a test.

To be clear, the desired behavior is to run builds as soon as VCS checkins are detected which are newer than the last build.

This seems obvious.  I can't imagine JetBrains designed TeamCity to run builds only if the checkin happened while the server/build agent was running; and only using the projects configuration at the time of the checkin.

We must be doing something wrong.  I just don't know what it is yet.  I'm still dilligently reading the manual.

Anyone else out there experiance this, or have the correct settings we need?

--
Marshall

0
Comment actions Permalink

It appears that the very first build you need to kick off by hand. This might be a deliberate design feature to avoid noisily failing builds starting while you are still configuring the build, as more complex build configs might take several steps to get right (e.g. add unit test watching, tweak dependencies, tweak build result handling, build parameters etc).

0
Comment actions Permalink

Christian,

I can't confirm your statement.  Although, I have encountered such a requirement on at least one of the prior CI products mentioned.  I can't remember which one at this moment.

Test 1:  I created another project, and did not run an initial build.  I then committed a change to revision control.
Results:  TeamCity built it fine.

Test 2:  I started editing the build settings for this project.  During that time, I committed another change to revision control.
Results:  TeamCity built the project fine.

Test 3:  I shut down TeamCity build agent and server.  I then committed yet another change to revision control.  Afterwards, I started up the TeamCity server and build agent.
Results:  TeamCity built the project fine.

Test 4:
     
(a)  I disabled the build trigger, then committed another change to revision control.
     (b)  I re-enabled the build trigger.
Results:  After step (a), TeamCity went to "Pending (1)" and stayed that way.  After step (b), TeamCity stayed at "Pending (1)".

I completely agree with your "noisily failing builds" statement.  No CI product should change how its builds operate until an admin gives the final "Save All My Changes".  Unfortunately, TeamCity's build settings aren't currently designed this way.

0
Comment actions Permalink

OK, I just found the answer.  I swear I searched the bug logs before posting; guess I missed it.

This is a new behvior for TeamCity 7.1.

In summary, if a build is disabled, or in my original case never configured, any VCS changes detected will not be built after re-enabling the build.  TW-22070 says this is for builds which are set to "Trigger a build on each check-in"; however, I see this behavior whether or not that setting is selected.  After reading why they implemented this change, it seems like a good idea to me.

Too bad I can’t mark my own post as the “Correct Answer”.  :(

--
Marshall

0
Comment actions Permalink

Nice catch...

I guess i never ran into this, since I never use the "build once for every commit" feature, after trying it once and seeing my build queue grow so long that it took most of the day to work off (my devs are very push-happy).

0

Please sign in to leave a comment.