Is there an Operation Behavior on Delete Build Result??

Hi Matt

Thanks for your answer!

We are in the process of moving various source types into RTC. Each of these have different build behaviors, but the result of the build is placed in an artifactory. For some buildresults we would allow the developers to delete them if the results (runtime parts) are not to be deployed. I would like to call my artifactory, querying if the artifacts are in fact deployed, and if so, deny deletion of the buildresult or at least, for some stages, allow deletion but also delete the runtime artifacts.

I would have liked to extent RTC by adding this behavior, but will, if not recommended otherwise, just not grant the permission and extent the popup menu on a build result with my own function.

Hope that make sense?

-Henrik

Matt's correct. All the build artifact modification operations are process-enabled, but only a few of them provide useful data about the item being acted on, as listed in the wiki page (I just added Abandon Build too). All the others just pass null currently, which is unfortunate. Not sure why it was done this way originally. I think there was some concern about people doing long-running, blocking operations like talking to an external server (process preconditions and follow-up actions are run during the overall DB transaction, which could result in DB locks being held a long time).

Hi Nick

I have created a webservice that is called from our artifactory if the artifacts are not deployed and deletion therefore allowed.
I think I will use the Deletion Allowed (isDeleteAllowed()) flag also - good idea!

Thanks a lot for your reply!