Is there an Operation Behavior on Delete Build Result??
Henrik Sloth (48●5●14)
| asked Dec 16 '13, 8:10 a.m.
retagged Dec 16 '13, 11:11 a.m. by David Lafreniere (4.8k●7) Hi ... How can I prevent deletion of Build Results? I was looking for a pre condition Operation Behavior which makes it possible for 'me' to prevent deletion of Build Results in certain cases and add additional 'events'. Anyone who can tell me how to do this or if the Jazz Team are planning something like that? Thx in advance! |
One answer
Hi Henrik.
You can certainly use project area and team area permissions to control *who* can delete build results, I don't believe there is a precondition that lets you *extend* the behavior of the operation. Here's the list of supported RTC preconditions as of 3.0.1.x - I don't believe "delete build results" has been added since then:
https://jazz.net/wiki/bin/view/Main/CustomPreconditionsLandingSite
-Matt
Comments 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).
For doing the kind of synchronization you're talking about, there are some other possibilities:
- when the build is deployed, programmatically check its "can be deleted" flag
- run a period process to collect RTC builds and see if their target is still deployed, if not uncheck the flag and delete the build (or let the build pruner do it)
- could also query for build deleted events (unfortunately these don't show up in the build feed currently, but they're available to be queried) to do the deletion more incrementally
Hi Nick
|
