-
Bug
-
Resolution: Unresolved
-
Critical
-
None
When a baseline fails to be created, the promotion level of the previous baseline is being set to REJECTED. If a baseline is not created, then the promotion level should/can not be changed. See below:
Created baseline "I-TEST-CI-148" in component "test_comp".
Begin incrementally labeling baseline "I-TEST-CI-148".
cleartool: Error: Version map for baseline "R-TEST-CI-186" is unavailable.
cleartool: Error: Error incrementally labeling baseline "I-TEST-CI-148".
cleartool: Warning: Some of stream "test_CI"'s latest baselines are not labeled
Unlabeled baselines can't be recommended and can't be rebased to.
Use "cleartool chbl -incremental <baseline-selector>" to label these baselines:
I-TEST-CI-148 (component test_comp)
cleartool: Error: Could not label one or more baselines in stream "test_CI".
cleartool: Error: Unable to create baselines.
FATAL: UCM ClearCase failed. exit code=1
Failed to create baseline: java.io.IOException: cleartool did not return the expected exit code. Command line="mkbl -identical -comment I-TEST-CI-148 -full -view TEST-CI -comp test_comp@/vob I-TEST-CI-148", actual exit code=1
[WARNINGS] Skipping publisher since build result is FAILURE
[workspace] $ /opt/rational/clearcase/bin/cleartool chbl -c "Hudson set baseline to promotion level REJECTED" -level REJECTED I-TEST-CI-147@/vob
Changed baseline "I-TEST-CI-147".
I think I have found the problem with this issue and a related one. The problem occurs in the UcmMakeBaseline class when assigning the latestBaselines. First off, I'm not sure why this variable and the related getLatestBaselineNames method is plural. The call to cleartool's lsstream using the "%[latest_bls]Xp" format (I think - please correct me if I'm wrong) will always return only one, the latest, baseline. The case reported above occurs because after the baseline creation was attempted and reported as failed (I-TEST-CI-148), the realBaselineName was assigned to the latest baseline (found as I-TEST-CI-147).
In a related case I have multiple servers building the same component and laying down different baselines. When these jobs get triggered they can get their baselines mixed up. For example Job A begins building and loading the component files. Before it has finished loadinig Job B (which is building the same component) begins building/loading. When Job A goes to "record" its baseline it will find the baseline started by Job B, again due to the getLatestBaselines method.
I have created a replacement getLatestBaselineName method that keeps the same prototype/return (even though it will always contain only one) that uses the createdBaselines variable (see below). I also changed the "this.latestBaselines" assignment to use the replacement function. Could you please update/publish the fix.
Thanks
private List<String> getLatestBaselineName(ClearTool clearTool, String viewTag) throws Exception {
{ blName = baseline.getBaselineName(); }String output = clearTool.lsstream(null, viewTag, "%[latest_bls]Xp");
String prefix = "baseline:";
if (StringUtils.startsWith(output, prefix)) {
List<String> baselineName = new ArrayList<String>();
String[] baselineNamesEdit = output.split(prefix);
String[] baselineNamesSplit = baselineNamesEdit[1].split("@");
String suffix = baselineNamesSplit[1];
String blName = new String();
String fullBaselineName = new String();
for(Baseline baseline : this.createdBaselines)
System.out.println(blName);
{ System.out.println("found component"); baselineName.add(fullBaselineName); }System.out.println(suffix);
fullBaselineName = blName + "@" + suffix;
System.out.println(fullBaselineName);
if (StringUtils.isNotEmpty(blName)) {
// Retrict to baseline bind to read/write component
String blComp = getComponentforBaseline(clearTool, fullBaselineName);
if (this.readWriteComponents.contains(blComp))
}
return baselineName;
}
throw new Exception("Failed to get baselinename, reason: " + output);
}