Thomas,

Thanks for your interest and questions. There's one RationalBuildForgeConnector engine for each instance of RTC which can be used by all of your Project Areas. Once it's created in one Project Area, when you create another build definition in a different project area, once you save it it should automatically select the global build engine. Since we have only one set of tasks for the server process, there currently does not need to be multiple instances. This is being changed in an upcoming release though (see below).

The build userid and password represents the Build Forge services layer API authentication information. This is currently the only way to securely connect to Build Forge in order to launch a build. This is not the "RTC" user's id/pass. That user must have proper permissions before being able to request a new build. This is a dedicated BF services layer ID used to protect access to the services layer. Since this is a distributed connection, it needs to be secured somehow. While you can connect over SSL (to SSL port 49150), we currently do not support certificate login to the services layer or other advanced security such as Kerberos. This can be added as a requirement though.

Currently, the RTC/BF integration does not natively support Personal Builds, although it's possible to do this on your own. You can add a property indicating a personal build, which lets you decided to skip the accept step and build the current workspace property. If you want more information on this, let me know. We plan to support personal builds with the BF integration in a future release (see below).

Personal Build requirement: https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/104552

Build Engine Restructure requirement
https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/62147

Regards,
Pete

My concern here is vibility. We leverage Access Control in our project areas and the RationalBuildForgeConnector must be owned by a Project or Team Area. If a user wants to request a build that must use the RationalBuildForgeConnector, he or she must be a member of that Project or team area, otherwise the build is disallowed.

For this issue, it's the BF services layer ID/pass that determines which Projects are visible to that particular "build definition". When you click "Get Projects", the list of visible projects will display. So you need to choose a dedicated services layer ID which will make the project visible that you want to share with your RTC users. Any RTC user, with rights to launch a build request, would be able to use the project (even though they may not be in the Build Forge user repository at all). What I'm trying to say, is you can allow or deny the launching of any BF project based on the services layer ID you choose. You can allow or deny any RTC user the ability to launch a build within a project area based on the permissions for that user in that project area.

Pete

However, in the examples provided there are two properties that are sent to Build Forge, Build_User and Build_Password. These represent the RTC build user that must be present to populate information about the build back to RTC for the build results. This information is in clear text in the properties of the build defintion and the resultant build result. Using the the Jazz Build Engine we are able to encrypt a file and point to the file for the build user password. Will thier or is their a way to dow this with the JazzSCM adapter?

For this issue, you can move "Build_User" and "Build_Password" out of the Project environment and into a Step Environment or Server Environment so that the user/pass stays on the BF side and does not get sent back to RTC. It would still be usable in the BF project to call back to RTC. You can make the password a hidden property there. The example has this property as a Project environment which gets sent back to the RTC properties list during a build definition Save. It's not necessary to do it that way.


Regards,
Pete