Perforce clientspec constistency

When I configure a TeamCity project to use a specific clientspec, isn't it supposed to use that clientspec when syncing to the head revision before building? What I'm seeing is that although my projects build just fine, if I try to manipulate the state of the clientspec in a subsequent project, or outside of TeamCity using the p4 command line or the p4win application, the clientspec shows no files synced to the client. This means that I can't use ssindex to index symbols, or label the sources appropriately.

I'm guessing that I could fudge this by syncing or flushing manually inside my build scripts by using the p4 command line directly, but I don't think I can do this and still guarantee that I'm dealing with the exact same sources that TeamCity regards as having been used to compile the projects.

What am I missing here? I feel like I'm fighting the system by not using it properly, but I can't seem to discern how TC wants me to do it.

5 comments
Comment actions Permalink

Hello Wayne,

  TeamCity uses server-side checkout when obtaining files from Perforce. I.e. the working copy on build agent is not a real Perforce working copy and you cannot run perforce commands on it.

  To label perforce sources, you can use TeamCity's built-in labeling features.

  The true client-side checkout for perforce is a separate feature, and you can vote for it.

  An alternative approach, which you can use, is to handle p4 checkout yourself, from build script. To do this, choose "Do not checkout files automatically" option on VCS settings page for your build configuration.

  Hope, this clarifies things a bit.

  Regards,
  KIR

0
Comment actions Permalink

OK... I'm not sure what's meant by a "server-side checkout", but if the approach you're describing is the only way TeamCity handles SCC, it seems fundamentally broken to me, and I'm a little disappointed, since my evaluation of the product was meeting with some success, and I was quite impressed with the transparency we were able to add to our build process for our entire team.

If I have to do all of the SCC management in my build scripts, there's no way for me to guarantee that the change report generated by TeamCity actually matches what got built, and a subsequent symbol indexing, store and label will also not correspond with the TC change report. I had imagined that the whole point of a continuous integration build would be to avoid some of the overhead and complexity to managing such "change reporting", and allow us to do more frequent incremental builds while at the same time knowing exactly what changes were in any given build.

It's entirely possible that a checkin (say checkin A) triggers a build (at which point TC syncs its copy, generates a change report including changes in checkin A and starts my script), and then before my script syncs the P4 clientview that I'm actually going to use to do the build, another checkin (checkin B) happens. At this point TC thinks that this build only includes checkin A, and would label to that effect, but in fact the build also includes checkin B, and my script's label command would include this. So everything that happens in my build script would be consistent (with the Perforce clientview), but users of the TeamCity screens would get a completely different story.

Am I missing something? Is there another way to ensure consistency if I'm managing SCC myself?

Thanks,
WMB

0
Comment actions Permalink

Hello Wayne,

  Could you please describe what Perforce operations do you have to run from within your build and why you need perforce access from your build scripts?
  There are chances that TeamCity can handle required operations (like labeling) itself.

  Regards,
  KIR

0
Comment actions Permalink

Sure. We index all PDB files against the currently synced sources and store them in a symbol server. We use p4index/ssindex for the indexing, which internally requests the current Perforce revision number of every source file used during the build using "srctool -r" and the P4 command "p4 have ...". This command returns the depot location and P4 revision number of every file synced in the active clientspec (in the P4CLIENT environment variable).

When run from any script started from TeamCity, the "p4 have ..." command always returns "files not in client" (unless of course some other stimulus has caused the P4 clientspec to be synced in some way -- but then there's no guarantee that the sources actually used during the build match those that TeamCity synced with and is reporting in its change list for the build).

UPDATE: Actually, I think I can use build.vcs.number to get around this. I think that during my build script I can do 'p4 sync ...@%BUILD_VCS_NUMBER%', this will sync my client with the same revisions that TC synced with, regardless of whether or not any additional changes were made in the interim. That should keep p4index happy.

Thanks.

0
Comment actions Permalink

Hello,

  Regarding consistency of the manual checkout to the change information shown by TeamCity - you can use build.vcs.number.* properties to get information what version of sources to checkout.
  In this case, you'll be able to checkout sources consistently with the information shown in TeamCity UI.

  Hope this helps and sorry that P4 checkout is not supported out of the box for your case

  Regards,
  KIR

0

Please sign in to leave a comment.