How to check with Bamboo's API if a task is run on a remote agent

[Michael T.]

Hi,

I have a task that is not able to be run on a remote agent because it needs various API's from Bamboo only  available on local agents (ImpersonationService, TransactionTemplate, etc.). When customers run this task on a remote agent, all they get is an unfriendly 

Error creating bean with name ... Unsatisfied dependency expressed through constructor argument with index 0 of type [com.atlassian.bamboo.applinks.ImpersonationService

error. Because this error is not very readable for users, I want to show them a better error message.

Is there any possibility to achieve that? In the task itself I cannot do this because it cannot be instantiated because of the above depenency injection errors. But is there a way to recognize the fact that the task is run on a remote agent in a RuntimeTaskDataProvider? If yes, how can I check this?

Thanks,

Michael

[Krystian Brazulewicz]

Using this kind of API by task is very risky. General rules are:

• task must never interact with DB (TransactionTemplate)
• task should never elevate its permissions (ImpersonationService)

Can you describe briefly what you're trying to achieve?

[Michael T.]

Thanks for your reply. Could you please explain what you mean by "this kind of API by task is very risky"? In my task I need these services to create Bamboo entities like plans and stages. But because these dependencies are not available on a remote agent, I want to let the user know of this restriction without failing with the mentioned dependency error.

[Krystian Brazulewicz]

Can you please provide high level overview of how your task works? 

Your brief description suggests that you're injecting plan configuration directly into database from a task. I don't want to comment on that until you confirm. 

From the architectural point of view much more preferred solution should be putting your logic into the the REST endpoint and calling it either from external script or eventually from a task. 

[Michael T.]

The task alters plan configurations based on the tasks input which is taken from a Git repository (a VCS checkout task comes right before this task). This allows me to alter plans right after I push some changes in the textual configuration to my Git repository. So this wouldn't work if I would just provide a REST endpoint in the same way. 

Is there something architecturally wrong with my approach?

[Michael T.]

Also, could you please go into more detail why a task must never interact with the database and elevate its permissions? Is that even the case when we use TransactionTemplate in the task and only run it on local agents?