Buildengine fails to connect to server

Hi,

after migrating from RTC 1.0.1 to RTC 2.0, I tried to start the new build engine. When it tries to access the service, I always get the following error:

CRRTC3527E: Operation blocked by process: 'Control The Build Lifecycle' failed. Permission denied. You don't have permission to perform the following actions:
Retrieve the Next Build Request (getNextRequest)

I did not change permissions, and the user used by the build engine has builduser rights.
Maybe this is because I had to kill a jbe process manually before?

Regards,
Martin

We've just run into exactly the same issue. We were able to determine that a different user could do this. Turned out that this user was a member of the project. Putting our automated build user into the project solved the issue.

This of course raises the question - is this a defect or by design? I did a brief search through the work items and couldn't find anything either way.

Hi,

after migrating from RTC 1.0.1 to RTC 2.0, I tried to start the new build engine. When it tries to access the service, I always get the following error:

CRRTC3527E: Operation blocked by process: 'Control The Build Lifecycle' failed. Permission denied. You don't have permission to perform the following actions:
Retrieve the Next Build Request (getNextRequest)

I did not change permissions, and the user used by the build engine has builduser rights.
Maybe this is because I had to kill a jbe process manually before?

Regards,
Martin

I ran into exactly the same problem and resolved it also by adding "build" to the team. Interesting: In the "JUnit" example "build" is NOT a team member, but the build works.

Regards

Thomas

In the JUnit example, the Everyone role has permission for the relevant Build operations.

In general the process configuration (or customization) for the project or team area owning the build engine item must grant permission to the following Build operations to the user specified on the JBE command line:
Control the Build Lifecycle
Save Build Engine
Save Build Result

and, if the script requests builds, add Request Build too.

Also (in order for it to update average build times) the build user should have permission to Save Build Definition in the project or team area owning the build definitions supported by the build engine.

Also, the owner of the build workspace (specified in the Jazz SCM page of the build definition) needs to be the same as the user running JBE. Or, if doing the accept/fetch from the script using the teamAccept/teamFetch Ant tasks, it must be the user specified in the task invocation.

Nick - we didn't change anything and after the upgrade to 2.0 it stopped working for us.

The team the build user was a member of did not have any permissions related customizations and the default team permissions at the project level had all build permissions enabled for all roles except "Everyone". The build user was in one of the roles which had all permissions granted.

I don't have time to go back and test this by moving the user out of the project again right now as it will affect some production work. I will see if I can do this later.

A couple of things to check:
- Is the team area associated with the build engine the same team area the build user is a member of?
- Check the user id of the build user in the team area. Is it the same as specified on the JBE command line?
- Is it possible multiple build users got created with the same user id?

I know you say nothing changed, but it doesn't hurt to double-check these. There could have been an error during import for example. Generalizing ownership of build definitions and engines from a team area to a process area (project area or team area) is one of the main model changes between 1.0 and 2.0 (and similarly in several other components).

A couple of things to check:
- Is the team area associated with the build engine the same team area the build user is a member of?
- Check the user id of the build user in the team area. Is it the same as specified on the JBE command line?
- Is it possible multiple build users got created with the same user id?

I know you say nothing changed, but it doesn't hurt to double-check these. There could have been an error during import for example. Generalizing ownership of build definitions and engines from a team area to a process area (project area or team area) is one of the main model changes between 1.0 and 2.0 (and similarly in several other components).

I think the first one is the likely cause. I've found 2 out of 8 build engines that were associated with the project, not a team. I don't know if the project members changed something right after the migration or these engines were somehow reconfigured in the import.

I'd be very surprised if this happened during import. While the BuildEngine field ITeamAreaHandle teamArea was changed to IProcessAreaHandle processArea in 2.0, and the migration moved the existing team area setting over, I don't see any way the team area could have gotten replaced with the containing project.