If there are many repos that require similar, but not exactly identical policies, it is inconvenient to manually replicate policies. Provide an easy-to-use solution to this problem.
Policy replication / template based policies
Have more questions? Submit a request
-
George Ivanov This feature (with the addition of having the ability to copy/clone rules within a policy as well) will prove immensely useful for complex policies, containing dozens of rules and conditions.
Having to manually enter (or shift between screens and then cut and paste stuff) is very inconvenient to say the least.
A good example/use-case to give is that due to another limitation of the plugin (described in #4458 and #2429), we need to create two sets of policies that are broadly similar (one for regular commits and one only for merges).
As things stand, the only way to do that is with shifting between two browser screens/tabs and cut and paste each and every rule's input field between the two policies (they have about 42 rules each!), which is a labourious task.
The sooner this feature gets developed and released, the better.
-
Mark O'Brien I was referred by support to comment here.
A single detailed multiple rule/condition commit policy that reflects an organizations development process cannot be applied to all repositories when even one condition of one rule has project specific aspects. This clearly can become big pain points for administrators as now
(1) the complete custom commit policy have to be reconstructed by hand for each project [[-- this can be supported by some form of template/copying of commit policies --]]
(2) any update/change to the organization's universal process checks has to be made manually in each project's existing commit policy. [[-- this will require a more creative architecture solution, maybe XML/JSON dump of all the commit polices, make updates to the dumpfile, then use it to upload and update/add to/replace the commit policy set --]]
-
Aron Gombas A user suggests making it even more powerful so that variables can be passed from the evaluator side.
For example, passing the PROJECT_KEY from Bitbucket side. (Of course, it expects that Bitbucket project are identical with Jira projects.)
"if you could take it one step further… if %PROJECT_KEY% value could be auto passed by the commit policy transaction, that would be a HUGE win. Then most, if not all bitbucket projects, could use the SAME JIRA commit policy."
+ He also suggests passing the Bitbucket project key:
Setup a “commit policy addon” variable, say, “BITBUCKET_KEY”. Each commit policy execution, auto determines, and passes the (all uppercase) Bitbucket key as part of the commit policy run/check and the variable is replaced before the commit policy rules are executed. If the commit policy uses that variable, great, if not then it is ignored and things carryon as normal.
We use the same key for JIRA/Bitbucket projects, so it would work as a project key replacement. However, for those that don’t use the same for both, it should not be too hard to create the needed setup in JIRA to be able to use a common JQL leveraging the BITBUCKET_KEY variable to limit the viable issues for the commit check.
The goal of all my communications with you is hoping to get closer one commit policy (common process) for all our projects, but ensure each project uses its own project artifacts. Having this BITBUCKET_KEY variable may well solve a lot of admin headaches, and it’s implementation should (hopefully) by somewhat simple and should not impact any existing customers/setups.
+ More related idea:
Following up on the commit policy addon variable, if it’s easier to define a value (on the bitbucket side) in a bitbucket project or repository (instead of trying to auto discover a bitbucket key) that would be better.
Have a configurable string field on the bitbucket commit policy side, project/repo settings. Pass that value as a “COMMITPOLICY_VAR” variable. This would be more flexible, actual JIRA Keys can be used or thing. If blank, nothing passed.
-
Aron Gombas To make this idea even more powerful, we should consider passing the template variables from the hook script! That way the different parametrizations are not maintained in the web UI, but in the hooks themselves.
Please note that Commit Policy for Bitbucket itself is a type of hook, therefore it should also support defining variables and even support implicit variables (ex: Bitbucket project key, Bitbucket project name, repo key, repo name).
As the user suggests:
Just want to note that implementing a bitbucket commit policy configurable variable (project/repo level config) for consumption during execution of jira commit policy checks would greatly reduce or even remove the need for a template copy/live implementation.
Why? One would only need create one commit policy per business rule sets instead creating many commit policies for the same business rule sets due to the situation where project info has to be hard coded.
The template copy/live update enhancement may be a way to help lessen the pain of managing all the project instantiations of the same business rule sets, but a user configurable variable enhancement would allow for single commit policy instance per business rule set (which resolves a pain point as opposed to making it more bearable).
Bottom line (from my perspective), templates may easy the admin pain points for commit policy instantiations due to hard coded project info, but a bitbucket commit policy config variable can eliminate that pain point.
-
Mark O'Brien Hello,
Has there been any movement on this? (reference: https://midori.zendesk.com/hc/en-us/requests/4875)
We are starting to prepare to setup and roll out a single commit policy rule set in our production env. It would be great to be able to create one commit policy rule set and apply it to all projects (using a config variable for project key). However, it looks like we need to create 40-50 commit policies that only differ in the JIRA project key present in the JQL.
Mark
-
Aron Gombas Mark, there is no update. As soon as there is, it will be posted here.
-
Mark O'Brien Is this being addressed? We have close to 80 commit policies, all using the same exact set of rules/conditions except for the JIRA project key present in the policy's regex expressions and JQL.
Now we discovered an issue and have to make a small tweak to the regex in a rule condition. Now I have to edit all 80 policies.
Is there some relief to this maintenance overhead in the pipeline? Resolution planned anytime soon?
-
Aron Gombas Mark, still no update. There is a useful workaround to mass-update policies directly via the Jira database. If you're interested, please open a ticket.
-
Gary Miner I also need this functionality. A way to pass in variables and copy existing rules is sorely needed here.
Please sign in to leave a comment.
9 Comments