Build Result UUID is not being set with Request
I have read through Peter's articles and I am trying to add the accept changes and some advanced contributions but I am stuck with all commands failing that I do not have the UUID.
https://jazz.net/wiki/bin/view/Main/RationalBuildForge/IntegrationWithRTC#Work_with_Build_Forge_specific_p Says the "buildResultUuid" should be set automatically, but I am having some issues making this work, namely where is this set and where can it be accessed from? If I do not include buildResultUuid in the BF Environment, I get duplicates of each step on the RTC side and the build completes with a warning that all activities failed to complete. In this case, there is no property generated for buildResultUuid. ( This seems to be a problem behavior, because a full shutdown of both BF/JTS and this will not fail like this, but still not UUID) I turned on client side tracing for the BF connector but that does not seem to provide any insight, here is what I am seeing output to the console.
If I add it to the BF environment, then the property is present during request build and is set to "default", everything runs properly all activities are completes successfully in terms of the activities, but the steps that use buildResultUuid fail because the value is "default" and not a real UUID. I've tried a number of different combinations but I can't seem to find a good one so I am open to any suggestions or pointers on what might be going on here or how to proceed ? I have two setups at different versions where neither of them seem to be working properly, so I can't play the spot the difference game. My first couple questions are: * Should the buildResultUuid variable be defined in the BF ENV? * If not in BF, do I need to define buildResultUuid explicitly as a property in RTC? * When I look at the build definition inside RTC should I see buildResultUuid property? -Sean |
8 answers
Sean, First, you need to make sure your Build Forge project has a Project-level Environment set. This is required as this is where the buildResultUuid is updated from. When you query the Projects in the Build Forge build definition, the buildResultUuid property gets set in the Project-level environment at that time. Then, when you submit a build request, the Build Loop scheduled task will update the "Build" environment that's a copy of the "Project" environment, overwriting the "default" value with the correct UUID for that particular build result object. This is only done if the "buildResultUuid " property got set correctly and exists in the Build environment at the time of the build submission. After saving the build definition, you should be able to see the buildResultUuid property in the Build Forge environment associated with the Project that you are running. The value will be "default" when viewed there. It only gets updated with the correct value during a build submission. If you continue to get "default" in this property and you have setup a Project environment and then queried the Project in the build definition where it sets this up, then you should enable trace on the server-side and recreate the problem. To enable trace, add -Dcom.buildforge.rtc.plugin.debug=true to the server.startup.bat JAVA_OPTS line. Restart RTC and a buildforge_service.log will appear in the startup directory after a build request is submitted. Let me know if you have any questions... Regards, Pete |
|
Pete,
Thanks for the feedback, so I have added the buildResultUuid back to the project environment, and restarted both systems to get rid of the activities not completing issue. So I have the debug option in the JTS startup bat script, and recreated the problem with the simplest scenario I could, the BF side is a simple project with a simple environment only containing buildResultUuid and a single step that echo's it's value. The result is still "default" as setup in BF. Not sure what I am looking for here, so I hope this is usable if I put the whole log inline. (looks like these forums have a size limit, so I put it up here for now) http://pastebin.com/4ByHMaaU -Sean |
Pete, Sean, Can you let me know the version of the plugins you have in the jazz/server/buildforgeconnector-update-site/plugins directory? I want to make sure it contains the code to update buildResultUuid in the build loop task. Thanks. Pete |
com.ibm.rational.connector.buildforge.server.feature_7.1.1.2020034.jar -Sean |
com.ibm.rational.connector.buildforge.server.feature_7.1.1.2020034.jar -Sean Sean, This is the issue. You must use BF 7.1.1.3 or later for this to work. That's described in the jazz.net article, but I may need to make it more clear. Once you upgrade and use a 7.1.1.3 or later plugin, then it will update for you. The following is directly from the article. "The scenario documented here is not possible without using the 7.1.1.3 Build Forge plugin (or later). Additionally, to use the continuous integration function in the provided Build Forge adapter, you will need to download the attached server-side connector ( BuildForgeConnectorServer-7.1.1.4-0-0010.zip ) which contains a fix to handle a problem found with this scenario. This fix will appear in the Build Forge 7.1.1.4 plugin. The 7.1.1.3 version (or later) of the plugin sends the buildResultUuid back to Build Forge to use as a parameter in the Ant Tasks. This is what allows the linkage to occur so that the Ant Tasks know what Build Result to publish back into." Pete |
|
Pete,
Thanks for your patience here, as you can tell I was banging my head against the desk when I saw your post, I will upgrade this machine and try again, but for now I tried out the same steps on a 7.1.1.3 machine that I need for a different client and it is working as expected. I shouldn't have a problem remembering what release this feature is included on moving forward ;) Thank you, Sean |
Pete, Sean, No problem, glad you've got it working. The best way to figure this stuff out is to try it one way and then the other. Pete |
We are currently using BuildForge 7.1.1.3 on zLinux, and when RTC 3 calls a job on buildforge, the buildResultUUID is simply set to default. After synchornizing between the RTC build definition and BuildForge, the property shows up in the project environment with a value of default. Do we need to install a patch on the 7.1.1.3 server to get this to work?
Pete, Sean, No problem, glad you've got it working. The best way to figure this stuff out is to try it one way and then the other. Pete |
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.