trigger on merge
In order to be able to implement a condition on merge, such as requiring a peer review before merge, or a test build completing, I would like to see the ability to have a trigger on a merge operation. Today we can trigger on the check-in after starting a merge, but then if the condition is not met we are left with having to undo the merge (remove the pending changes). It would be much easier to implement this sort of "merge gate condition" if the trigger could be on the actual merge operation.
Todd Alden
shared this idea
[New] Release 6.0.16.1471
Added a new before-merge trigger. This trigger could be used to deny the merge of some branches if certain conditions are not met.
The trigger can be register using the following command:
[code]cm maketrigger before-merge merge_gate “/path/to/script” —server=myserver:8084[/code]
Check the [link] https://www.plasticscm.com/documentation/triggers/plastic-scm-version-control-triggers-guide.shtml#Chapter5:Detailedtriggerreference triggers reference[/link] to check all the available info on the merge trigger.
Remarks: the client and the server should be updated to use this functionality
-
[New] Release 6.0.16.1471
Added a new before-merge trigger. This trigger could be used to deny the merge of some branches if certain conditions are not met.
The trigger can be register using the following command:
[code]cm maketrigger before-merge merge_gate "/path/to/script" --server=myserver:8084[/code]Check the [link] https://www.plasticscm.com/documentation/triggers/plastic-scm-version-control-triggers-guide.shtml#Chapter5:Detailedtriggerreference triggers reference[/link] to check all the available info on the merge trigger.
Remarks: the client and the server should be updated to use this functionality
-
Hi Todd,
Questions:
* When you mean "on merge" I guess you mean a *server* trigger that runs before-merge, because the "after-merge" is already the checkin.
* There's no easy way to do an after-merge other than the checkin, because you don't know for sure if the merge was done, on the server side, in any other operation.
* The other problem with this is that the trigger should be run anytime you try to merge. I mean, on CLI you have the cm merge, but you can run it with or without the --merge flag. The trigger will need to be run on both, even if one is just a "test" to figure out what needs to be merged (like happens on the GUI,you open up the merge but you're not forced to really run it).
I say all these because the merge operation is not only a server-side operation, but most of it happens on the client, and as such the server doesn't know where to pull the trigger :-)
Because I guess a client-side trigger won't do the job, right? You need something central to enforce the op, correct?
Thanks!
-
Thanks Todd. Yep, we'll add that. We've to double check when to trigger (internal stuff related to how the protocol is designed) but I think we can do it.