How do I detect when a build trigger is deleted via UI

Hi,

I have a custom build trigger that uses CustomDataStorage to store state between each polling interval.

My question is simple, how can I programmatically detect when a build trigger is deleted via the UI?  Upon detection of this event, I would like to "reset" the parameters in CustomDataStorage entries for the current build context.  This functionality is required to circumvent a potential issue when a user deletes and then re-adds the same custom build trigger.

4 comments
Comment actions Permalink

Hello,

Do you implement jetbrains.buildServer.buildTriggers.PolledBuildTrigger to provide a policy to the trigger?
The implementation you recieve reference to jetbrains.buildServer.buildTriggers.PolledTriggerContext that provides access to a per-trigger parameters storage via jetbrains.buildServer.buildTriggers.PolledTriggerContext#getCustomDataStorage() method.

This storage should not be reused between similar triggers. Storage is reset if user changes any parameter of a trigger.
The only case storage is reused is when user specifies exactly same trigger parameters for the same build configuration/template.

0
Comment actions Permalink

Thanks Eugene - its just my luck that I happened to be testing what happens to values in CustomDataStorage when I was deleting and re-adding the same trigger with the same parameters and as you have confirmed, I was still seeing my old values in there which was causing an unexpected behaviour in my trigger logic.

I would have thought it would be more intuitive to expect the CustomDataStorage associated with the deleted PolledTriggerContext to also be deleted, as actually now it seems like CustomDataStorage is at a build context level.

Thanks,
Volkan

0
Comment actions Permalink

I agree with you. Still it is not clear for me host that could lead to unexpected behavior in the trigger.
Your trigger implementation should use storage and should be aware of sudden poweroffs or crashes or any other disasters.

It looks like your unexpected behavior may lead to severe bugs in the trigger implementation.
Still, it's ok if it only confused you in testing.

0
Comment actions Permalink

Yes its more that I was experiencing unexpected behaviour in my implementation of the trigger.

So when the trigger is run for the very first time, I take the current timestamp and put it in storage (check for null value when fetch value from storage), then I poll for one or more events in a database and update the storage timestamp accordingly when certain conditions have been met.

The key is that when the trigger is initially set up, it should only trigger a build AFTER the point it was created.

If I delete and re-add the trigger, this initialisation step will never take place as the value will still be in storage and so it may trigger a build and therby not holding to the requirement to trigger a build AFTER the point it was created/added to the build.

Anyway, not to worry - thanks for your help

0

Please sign in to leave a comment.