Not able to fetch the code - The UUID of the build engine is "default"
Saurabh Jain (5●6●8)
| asked Feb 11 '14, 11:56 a.m.
edited Feb 19 '14, 2:03 p.m. by Jennifer Cianchetta-Riordan (251●2)
Hello ,
I am trying to execute a build from eclipse RTC client, for the same I have create a build engine and a build definition. And after execution I am getting this message in the warning while executing first step of my BF project whcch is basically fetching of source code from RTC source control. The build engine is either not in the repository, or it cannot be accessed by the following user: "saujain". The UUID of the build engine is "default". I crosschecked my engine exists in the repository and I have permission of requesting build for my userid - saujain . Why it is showing the UUID of build engine us default ?? Is it correct ? Please advice , where I am doing mistake. Thank You |
Accepted answer
It is likely that you do not have an environment assigned to the project that is getting executed in BF from RTC. RTC has to synchronize the properties from its build definition to the BF project, so there must be an environment assigned so there is somewhere to save the properties. The engine getting assigned to Default in this case just means that the real engine value from RTC was never written to BF. So verify that the property engineUUID exists in an environment assigned to the BF project getting executed from RTC.
~Spencer
Saurabh Jain selected this answer as the correct answer
Comments Hi Spencer,
> Or should these properties(engineUUID and buidResultUUID) will also be visible in RTC ?
Actually, many of the RTC-specific properties are hidden on the build definition, but Synchronize Properties should still add them. You can check by trying to add a property manually, e.g. engineUUID or buildResultUUID. If it has already been added, the add property dialog should warn that there's already a property with that name. Hello Nick ,
I suspect changing from "default" to empty string was just a coincidence. It might have been failing to propagate the value earlier due to connection problems. On the RTC side, it doesn't care what the value is on the BF env, it just sets the value from RTC. Hi Nick,
That's really odd. Is there any corresponding error entry in the RTC server-side ccm.log?
As for the hidden properties, most of the properties added to the BF environment correspond to built-in attributes of the build/engine, or to properties that are provided in other pages in the RTC build definition, e.g. the SCM settings, so there's no need to make them visible in the Properties page. Other properties in the BF environment that are not 'special' should show as regular properties in RTC. I can appreciate that the hidden properties can be confusing, though. We might reconsider of the non-SCM ones.
I checked in the RTC server logs , but there is no such error.
Try doing Show Repository Files on the component in the stream, as well as in the build workspace (the repository workspace, not the loaded sandbox). Do the .java files show there? Do you have any load rules configured in the build definition that might be excluding files? Could there be a script running after the load that's deleting .java files? 1.) doing Show Repository Files on the component in the stream ?
Can you try loading the build workspace into your RTC Eclipse client? Do the .java files come through then? I am not sure i correctly understood "loading the build workspace into your RTC Eclipse client" .
1 thing that i noticed just now , it is copying some of the files and skipping others.
Any errors in the step log for the first BF step (the one running JBE)? these are the last few lines of BF step log ... i think either its a timeout issue or Warning
274 2/14/14 4:28 PM WARNING Status WARNING: com.ibm.team.filesystem.client code=0 Problem detected: your filesystem supports symlinks but you are missing the Eclipse native support for them null275 2/14/14 4:33 PM TMO Timeout after 300 seconds.276 2/14/14 4:33 PM RESULT 999277 2/14/14 4:33 PM INT CRRBF0878I: Env Group '[ADAPTOR]' variable 'Last_Run' set to [].278 2/14/14 4:33 PM INT Finished Block Processing.279 2/14/14 4:33 PM MJC CRRBF1576I: Call JazzJBE adapter and fetch source code completed (0) Ah, it looks like the SCM step is timing out after 5 mins. This can be adjusted on the step in BF. Is the workspace large? Is it expected that it would take >5 mins to do the accept/fetch? Yeah repository contains lot of projects and I am expecting it will take more that 10 mins.
Update :
277 2/14/14 5:03 PM EXEC Feb 14, 2014 5:18:00 PM com.ibm.team.filesystem.client.internal.LoggingHelper log 278 2/14/14 5:03 PM WARNING Status WARNING: com.ibm.team.filesystem.client code=0 Problem detected: your filesystem supports symlinks but you are missing the Eclipse native support for them null 279 2/14/14 5:09 PM ERROR An exception was thrown by the step provider runtime. 280 2/14/14 5:09 PM ERROR CRRBF0218I: Timeout after 360 seconds.Please suggest what to change now. I'm not aware about what a "__TIMEOUT" env vars does. The error shown indicates that the step in BF still has a low timeout (360 secs = 6 mins, which is different than the default of 5 mins). Try:
- navigate to project in Build Forge
- click the step that runs the SCM phase (first step usually)
- check its setting for 'Timeout in minutes'
- try changing this to something large like 30 mins
Nick ,
360 is the default timeout for the Eclipse client. Try adding a: -vmargs -Dcom.ibm.team.repository.common.transport. TeamServerConfiguration.socketTimeout=900000to the end of the JBE execution in the adaptor script. The _TIMEOUT is a BFA value that overrides the BFA default timeout value, but BFA is not reporting the time out here.
~Spencer
Spencer ,
.source JazzJBE I don't think it's the JBE requests timing out. The default timeout there is 480 seconds (8 minutes), and the error would be different if that was the case.
The error:
> ERROR CRRBF0218I: Timeout after 360 seconds.
Is clearly from Build Forge.
Spencer, is there some global timeout setting that needs to be changed?
also the -vmargs -D… would have to go in the adapter, not added to the BF step. But as I said in the last comment, I don't think that's the issue, so I'd leave TeamServerConfiguration.socketTimeout as the default for now. Note that this timeout is for individual requests, not the overall runtime of JBE or the SCM accept/fetch. As this question is going out of context from the original question.
showing 5 of 25
show 20 more comments
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.