Perforce Client Spec. Update Issue

Hi,


I have just updated a P4 client spec. to include several new client spec mappings but TeamCity (4.0.1 build 8171) does not pickup the changes (new 3rd Party jars for build). I checked that the mapping paths where correct and everything looked fine. However, after several build attempts (using the 'Clean all files before build') the new files where still not being mapped into the agent work dir.

I then decided to rename the client spec. and run a build. Strangely this worked as the new mapped files where synced down correctly. It looks like the original Perforce client spec state had been cached somewhere (TeamCity or p4d?). I have seen this "caching" behaviour with P4 client specs. before and the usual fix is to do a force sync (e.g. sync -f from cmd line).

Has anyone experienced this behaviour with P4 client specs. and TeamCity? Are there any workarounds that don't requrie a client spec. rename?

Cheers

Paul

12 comments
Comment actions Permalink

Hello Paul,

  Could you please provide a sample change of the client spec which didn't work for you?
 
  By the moment, TeamCity doesn't take new changes in the client spec and this requires a 'clean' build (TW-6023).
  But it is naturally a serious bug if you need to rename client name to enforce the change.
 
  Kind regards,
  KIR

0
Comment actions Permalink

I have had a similar experience when changing a Perforce client spec.I believe that this is a TeamCity problem.

My solution was to remake the TeamCity VCS root after updating the Perforce client spec on which it is based.
I have done this multiple times.

To do this:

  • Delete the VCS root in the Version Control Settings part of the TeamCity build config.
  • Recreate the TeamCity VCS root. (You can use the same VCS root name and the same client spec).
  • Attach it to the TeamCity build config.


Unfortunately, if you have attached the VCS root to multiple build configs (as I tend to do), you will first have to detach
the VCS root from every build config to which it is attached. Then you will have to recreate the VCS root and then re-attach
it to all the build configs that use it.

-Dave

0
Comment actions Permalink

Hi Kirill,

There are the mappings that I added into the client spec:

//3rdparty/libs/spring-framework-2.5.6/dist/modules/spring-web.jar //build.repository/repository/lib/spring-web/spring-web.jar
//3rdparty/libs/spring-framework-2.5.6/dist/modules/spring-webmvc.jar //build.repository/repository/lib/spring-web/spring-webmvc.jar
//3rdparty/libs/spring-framework-2.5.6/dist/modules/spring-webmvc-struts.jar //build.repository/repository/lib/spring-web/spring-webmvc-struts.jar

Nothing out of the ordinary. I also check the TeamCity and Agent log and couldn't see any errors to indicate that the clean checkout had failed. I will be making further changes to the client spec. this week and if I experience further problems I will let you know.

Cheers

Paul

0
Comment actions Permalink

Hi Dave,

Thanks for the tip. If I experience further problems with client spec. changes I will try a remake of the project VCS route.

Cheers

Paul

0
Comment actions Permalink

Hello,

  I've just verified the problem existance in TeamCity 4.0.2.

  In fact, the following sequence of actions works just fine for me:

  - VCS Root uses some perforce client name
  - The client settings are altered
  - In TeamCity, for a build configuration with this VCS Root, invoke "Enforce clean checkout" action from "Actions" popup on the toolbar
  - After that, the next build shall contain sources from updated client spec.

  Does it work for you?

  Kind regards,
  KIR

0
Comment actions Permalink

Sorry for the delay in responding. We had need for majoe build chnages in a short time.

This did work for me:
1) Add an additional code path to an existing Perforce client spec for a build that was set to "Clean all files before build".
2) Run the build without stopping/starting TeamCity.
3) The result is that the additional code path now appears on the build client.

Maybe this was fixed a while back and I never noticed it.

-Dave

0
Comment actions Permalink

This has happened again:
- A build broke because a new code path needed to be added
- I added the code path to the Perforce client with "p4 -c <client-spec-name> client"
  Saved & verified it
- Ran the build through teamCity again and the build failed again with the same "Basedir ... does not exist." error.
- Stopped/started the TeamCity server: Failed again.
- Detached/reattched the build root. Failed again.
- The only solution that I tried that worked was:
  - Detach all build configs from  the build root
  - Delete the build root
  - Remake the build root
  - Reattach all the build configs.

0
Comment actions Permalink

Why did not you try to enforce clean checkout?

0
Comment actions Permalink

All of my build configs are set this way in the Version Control Settings:
- VCS Checkout Mode: Automatically on server
- Clean all files before build - enabled

0
Comment actions Permalink

I mean "Enforce clean checkout" action from the Actions menu on the build configuration home page. This action can also be invoked on per agent basis from the agent details page.
TeamCity internally maintains a cache of patches and if wrong patch is stored in the cache (as in your case because TC did not detect a change in client mapping) the simplest way to clear it is to use "Enforce clean checkout".
Checkbox "clean all files" is a bit different. TeamCIty still uses internal cache of patches when this option is enabled to speedup things and to avoid high load on VCS when several builds of such configuration run at the same time.

0
Comment actions Permalink

I finally found the setting you mentioned and changed it. It took me several minutes to find it. I had no idea that the setting existed and it was not in an obvious location.

It seems to me that the setting is in the wrong place. The ability to do this should be an admin function. It should be included on the right side of the main Administration page to globally change the setting for build clients and in the /admin/editBuild pages to change an individual build client.

Part of my confusion was because on the agent details page itself (for each of my build agents) it says in the Misc area:
There were no builds on this agent or you do not have enough permissions to clean sources of build configurations built on this agent.
This was despite the fact that from one of the Project viewType pages, I could change it to clean all sources for not only that build type but for a build agent as well.

Another confusing thing about this is that I don't seem to be able to change this back once this is set to "Enforce clean checkout", the only actions now listed in the Actions dropdown are: Pause build configuration & Check for pending changes.

Also, why is there a need for this setting at all if "clean all files" is enabled? I would expect that setting to take care of this.

0
Comment actions Permalink

I agree that this action is not easy to find. However it should not be used often. It is a workaround for the cases when significant changes were done in the repository but TeamCity is not able to detect them.

Note that sources are marked as dirty in the database. And this action is only available if TeamCity knows something about build configuration sources on the agent. The reason why this is not done as administrator action is because this action is not harmful, and it can be more convenient for developer (not administrator) to enforce clean checkout by himself.

As I told before "Clean all files" checkbox works a bit different. It uses caches. While "Enforce clean checkout" clears caches too. TeamCity can't stop to use caches if "Clean all files" option is turned on because this will slowdown builds significantly. Note that some of our users prefer to checkout all files for each build.

As for confusing behavior of "Enforce clean checkout" at the agent details page, if you are using TC 4.0.x then this is a known bug. It is already fixed in the 4.1 EAP. Sorry for inconvenience.

Anyway feel free to submit your suggestions to our tracker.

0

Please sign in to leave a comment.