|
Sort Order:
I'll give 5214 a try. We wanted to use NODE_NAME. However, our convention is to use the computername for the NODE_NAME, and for some of our nodes, the names are fairly long. In an effort to chop some characters off the view paths, we defined SHORT_COMPUTERNAME which is the last 8 characters of the computername. Thanks for the tip nonetheless. Did you happen to look at the patch I proposed to Well, testing with the 5214 continued to fail with the same error. Frankly, I'm not much surprised, since the 5214 fix was pretty much the same as one I tested this morning (arrived at by studying SCMTrigger). The only difference was the name of the method for getting the latest build and you made a better effort in the test class. I tried changing pollChanges to also pass the constructed BuildVariableResolver to generateNormalizedViewName a few lines later, and it continues to misbehave. I was very optimistic when I noticed that when generateNormalizedViewName is provided a build, it uses getCurrentComputer to supply the Computer for env resolution. Code changed in hudson I stripped out my patch for 2934, restored the plugin to trunk, rebuilt, and continue to face the same problem. We have about 25 jobs defined, all using clearcase. We use Hudson 1.339. Most jobs are set to poll "@hourly". There are 5 nodes in the cluster. Is there too much contention at the same time (they all seem to poll right around the hour)? The View Name for all of our jobs is "${SHORT_COMPUTERNAME}_${JOB_NAME}". I also changed line preceding the hasChanges call to "String normalizedViewName = generateNormalizedViewName((BuildVariableResolver) variableResolver);" and it continues to fail. When I debug, the generateNormalizedViewName seems to be at fault; the normalizedViewName is set to the wrong value for the lastBuild's Computer. When I debugged into the BuildVariableResolver, it seems that the problem is that the environment returned for the last build has the wrong value for the variable. If the Computer and build are switched in order, perhaps it will succeed. Our "SHORT_COMPUTERNAME" variable seems ill advised right now. Code changed in hudson I'll watch it more closely for a day or two, but it looks like it's working like a champ. Thanks for your support on this. Can you take a look at the patch I proposed for Is there a way to get hold of a build with this fix, we are currently suffering from this... If your organization doesn't use either Maven 2 and Subversion, install them. Read these. http://wiki.hudson-ci.org/display/HUDSON/Plugin+tutorial Do a Subversion update to get the latest to your machine. The url for the clearcase plugin is: https://svn.dev.java.net/svn/hudson/trunk/hudson/plugins/clearcase From the folder you create to house the plugin, do "mvn clean package" or "mvn package". I like to clean before every build because it updates the build timestamp that you see in the installed plugins tab in Hudson. The build creates a target folder inside the root one. It has the clearcase.hpi. You can either manually copy that to your plugins directory and restart Hudson or use the Hudson UI's pluginManager/advanced page to install it from the machine you build it on. Enjoy! Also, FYI, I'll be pushing a release of 1.1.1 (http://wiki.hudson-ci.org/display/HUDSON/ClearCase+Plugin#ClearCasePlugin-Version1.1.1 I look forward to the 1.1.1 release! I really appreciate your responsiveness on this stuff. Sorry about hounding you about 2934 (I'm a newbie to JIRA and SVN) and didn't get the notification (or notice) your comment on it. As a quick sanity check, I diffed our versions of the key files and found only one diff that I think will cause me a problem. On version 25724 of AbstractClearCaseSCM, you have generateNormalizedViewName(lastBuild) whereas I have generateNormalizedViewName(variableResolver). I think this will make a difference because the signature you're using defaults to the current computer when constructing a BuildVariableResolver. I need it to be the computer from the last build. |
|||||||||||||||||||||||||||||||||||||||
Bug
Resolved
Blocker
Wrong Computer used for SCM polling
I think
HUDSON-5214should actually address this - before 1.1, we were using a deprecated method for determining the Computer to use for build variable resolution. That deprecated method generally returned the Computer used for the previous build (the method is deprecated because it's not 100% reliable). In 1.1, we switched to using a method that returned the current Computer consistently, but that method, as it turned out, didn't work properly in polling, only during a build. So now we're using a different approach in polling than we are in the build itself - we're using a more reliable way of getting the Computer the previous build ran on in the polling, while still using the current Computer in the build proper. I think this approach should solve your problem - polling, so far as I can tell, runs on the Computer the last build of the project ran on, so we should be getting the right information.Also, while your per-Node parameter should work, you could just use NODE_NAME - that's specific to the ClearCase plugin's build variable resolver, but it gets you what you want.