Using Buildforge 7x to RTC 3x build definition get API: Access denied
Having finally got our RTC project connected to our Build Forge server, I get this while trying to run a build through the RTC build definition:
com.ibm.team.build.common.TeamBuildException: Error sending request "Create build for project af530bd50c621000ca2dd3c675547554" to Build Forge server at "172.172.172.172:3966" for build engine id "BF": API: Access denied.
at com.ibm.rational.buildforge.team.internal.service.BuildForgeConnection.createTeamBuildException(BuildForgeConnection.java:132)
at com.ibm.rational.buildforge.team.internal.service.BuildForgeConnection.runAsRetryable(BuildForgeConnection.java:99)
at com.ibm.rational.buildforge.team.internal.service.BuildForgeConnection.createBuild(BuildForgeConnection.java:430)
at com.ibm.rational.buildforge.team.internal.service.BuildForgeBuildLoopRunnable.startBuildForgeProject(BuildForgeBuildLoopRunnable.java:245)
at com.ibm.rational.buildforge.team.internal.service.BuildForgeBuildLoopRunnable.run(BuildForgeBuildLoopRunnable.java:193)
at com.ibm.rational.buildforge.team.internal.service.BuildForgeBuildLoopScheduledTask.runTask(BuildForgeBuildLoopScheduledTask.java:71)
at com.ibm.team.repository.service.async.AbstractAutoScheduledTask.executeTask(AbstractAutoScheduledTask.java:88)
at sun.reflect.GeneratedMethodAccessor129.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord.invoke(ExportProxyServiceRecord.java:361)
at org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord.access$0(ExportProxyServiceRecord.java:347)
at org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord$ExportedServiceInvocationHandler.invoke(ExportProxyServiceRecord.java:56)
at $Proxy487.executeTask(Unknown Source)
at com.ibm.team.repository.service.internal.scheduler.AsynchronousTaskRunner.runTask(AsynchronousTaskRunner.java:158)
at com.ibm.team.repository.service.internal.scheduler.AsynchronousTaskRunner.run(AsynchronousTaskRunner.java:119)
at java.lang.Thread.run(Thread.java:738)
Caused by: com.buildforge.services.common.api.APIException: Message[uuid=null, timestamp=1373498694, userUuid=, processId=0, severity=ERROR, type=, componentUuid=null, messageKey=APIAccessDenied, indirectionMask=0, args={}]
at com.buildforge.services.client.api.APIClientConnection.call(APIClientConnection.java:607)
at com.buildforge.services.client.dbo.Build.create(Build.java:569)
at com.ibm.rational.buildforge.team.internal.service.BuildForgeConnection$4.run(BuildForgeConnection.java:437)
at com.ibm.rational.buildforge.team.internal.service.BuildForgeConnection$4.run(BuildForgeConnection.java:1)
at com.ibm.rational.buildforge.team.internal.service.BuildForgeConnection.runAsRetryable(BuildForgeConnection.java:95)
... 15 more
Here's something interesting that may provide a clue: when I first set up the Environment on Build Forge to use the Jazz source code adapter, I had the wrong repository set. So when I ran it, I got an error that said:
2013-07-10 16:09:48 [Jazz build engine] Searching for buildResultUUID=_woYl4Om1EeKyK_0LrHLRhA
2013-07-10 16:09:48 [Jazz build engine] The -noComplete argument was specified. The build result will not be completed by JBE.
2013-07-10 16:09:48 [Jazz build engine] Building only the specified participants: "[com.ibm.team.build.jazzscm]"
2013-07-10 16:09:48 [Jazz build engine] Not using a proxy to reach https://ourrepo-address.org:9443/ccm
2013-07-10 16:09:51 [Jazz build engine] CRRTC3526W: Warning: The build engine is either not in the repository, or it cannot be accessed by the following user: "O386600". The UUID of the build engine is "_uUlzwOm0EeK3_LMAcS2E1w". For more details, open the help system and search for CRRTC3526W.
2013-07-10 16:09:51 [Jazz build engine] No requests found.
2013-07-10 16:09:51 [Jazz build engine] Exiting JBE after completing single build request, RC=1.
CRRTC3529W: The execution of Jazz Build Engine completed with a non-zero return code (RC=1). For more details, open the help system and search for CRRTC3529W.
ENDBFBomPlaceholder425838192bomp2
So this one is easy enough to understand. The point is that this was reported as an error for that particular step. The first error message (the one I'm having trouble with, above), is reported under the RTC build engine log as a ServerRunTimeError - yet, I don't get any step-related logs. It seems that once I advance to the point of connecting to RTC from the build agent, something happens that causes the server enough anxiety to completely abort and to throw an exception rather than report a step-related error.
Any ideas??
- Andy
Accepted answer
The APIAccessDenied is an authentication problem. Check that the user who is connecting to Build Forge has the right username/password. Then check that the user isn't locked in Build Forge.
~Spencer
The JBE wrong repository shouldn't have a bearing on this since it is strictly RTC and RTC authentication. The JBE execution only happens after the build is started in BF, and the first error indicates that we have the API auth failure before we can connect to BF and start the build via the services layer.
~Spencer
Comments
1 vote
1 vote
1 vote
showing 5 of 11
show 6 more comments
3 other answers
Hi All,
After a long test runs I ultimately got success in the issue. Actually I had more then one build engine each with different build userid. After Access Denied lets say I did expire the password for user, reset via RBF web console and again triggered the build as soon as I am using the same build engine it worked fine. The moment I trigger the different build engine the first one start getting the API access denied.
Simple resolution is to have only one user for all the build engine. Also if you have less user license then make the user used for build as priority user. That allow the build user to access the buld forge even all licenses occupied. Also if build user logged in , it will not be logged out by someone else.
- Make user as priority
- Use only one user for all build engine.
After a long test runs I ultimately got success in the issue. Actually I had more then one build engine each with different build userid. After Access Denied lets say I did expire the password for user, reset via RBF web console and again triggered the build as soon as I am using the same build engine it worked fine. The moment I trigger the different build engine the first one start getting the API access denied.
Simple resolution is to have only one user for all the build engine. Also if you have less user license then make the user used for build as priority user. That allow the build user to access the buld forge even all licenses occupied. Also if build user logged in , it will not be logged out by someone else.
- Make user as priority
- Use only one user for all build engine.
Hello ,
I am getting the issue in RTC4.0.3 with all users. my build forge is 7.1.3.3. And I all working till day before. Suddenly the issue appears. I used some builduser account got issue. Then I used my account I got success in first time and thats it it fails from next onward. I check my login and manual trigger as well. Its working fine.
Not I used root users but same happening with root user as well. If there is access issue why the root user also getting the issue.
I am getting the issue in RTC4.0.3 with all users. my build forge is 7.1.3.3. And I all working till day before. Suddenly the issue appears. I used some builduser account got issue. Then I used my account I got success in first time and thats it it fails from next onward. I check my login and manual trigger as well. Its working fine.
Not I used root users but same happening with root user as well. If there is access issue why the root user also getting the issue.
From Investigate "API: Access Denied" error in Build Forge builds (302262):
We discovered that BF can return APIAccessDenied instead of APILoginFailed if the request fails due to an expired session. The session timeout can be changed, or disabled, in the BF system settings. It's unclear why the session was timing out though.
There's a fix in 5.0.1 in item 317575.
There's a fix in 5.0.1 in item 317575.