|
Unknown macro: {vote}
Yes. |
Design
Rules can be defined both based on project (like in 1.x) and based on change path regular expressions. The evaluator in the plugin has two different entry points, when you install the client script, it will specify which entry point to call (which approach to take).
Approach: project based rules
Same project to rule mapping like in the 1.x versions. Not detailed here.
Approach: regex based rules
Rules are defined for changepath regular expressions, not JIRA projects.
The basic algorithm is extremely simple:
authenticate fetch issue details for each changefile in the changeset for each rule if rule.regex matches changefile.path and rule evaluates to FALSE reject commit and terminate accept commit
It means: if any changefile in the changeset violates any matching rule, the commit will be rejected.
(A more performant implementation of the same idea: create an empty set, then for each changefile, put its matching rules to the set, finally evaluate the rules in the set.)
UI Draft
"Create New Rule"
| Path Regex | Acceptance Rule | Action | |
|---|---|---|---|
| 1 | /* | Valid issue in the commit message. | Edit / Disable / Delete / Up / Down |
| 2 | /a/trunk/* | All issues referenced in UNRESOLVED. | Edit / Disable / Delete / Up / Down |
| 3 | /a/branches/1.1-rc1/* | All issues referenced assigned to the committer. All issues referenced in project TST. | Edit / Disable / Delete / Up / Down |
| 4 | /b/* | None. | Edit / Disable / Delete / Up / Down |
| 5 | /c/* Disabled | Valid issue in the commit message. | Edit / Enable / Delete / Up / Down |
"Edit" takes you to another screen where you can configure the predicates for that rule.
"Disable" and "Enable" temporarily turns a rule ON and OFF without deleting it.
"Up" and "Down" changes the display order only.
If you commit a changeset with two files /a/trunk/First.java and /b/apackage/Second.java, then it must satisfy rule #1, #2 and #4.
See a design for the 2-approach version here: 
Predicates
We basically keep the currently existing set of predicates, but make them a little more parametric:
- there is valid issue referenced
- there is at least one valid issue in project "XYZ" ("XYZ" is parameter!)
- all issues are in project "XYZ" ("XYZ" is parameter!)
- all issues are in "XYZ" state ("XYZ" is parameter!)
- all issues are assigned to the committer
(Another idea is instead of configuring the rules by checking checkbox and such in a web UI screen, we could have a text input box where users enter logical expressions or scripts (e.g. Groovy?) that are evaluated. Example,
issues.each { assignedToCommitter(it) } or issues.length = 0
This could give a lot more possibility (really complicated decisions, interacting with JIRA's facilities, custom predicates!), but requires experience on the administrators.)
Implementation
To support both approaches:
- Need to add two entry points in the evaluator:
acceptCommit(userName, password, committerName, projectKeys, commitMessage) // just like in 1.X acceptCommit(userName, password, committerName, changePaths, commitMessage) // changePaths is comma-separated strings
- Need to add two versions of each hook client script.
- Need to add one more Ant test script for functional testing
- See Spring's PathMatcher and its impelementation classes
Comments (10)
Sep 25, 2007
Gunnar Wagenknecht says:
Just a path regex matching on the server side is not sufficient. It brings SCM s...Just a path reg-ex matching on the server side is not sufficient. It brings SCM specific concepts (Subversion) into the server and blocks concepts from other systems (ClearCase). There has to be some abstraction on the client as well. Subversion manages the branch in the path but other systems do not.
Having the configuration in JIRA tight to a specific project is fine. However, the project key must not be static for a whole code repository. Some repositories contain possible hundreds of projects (eg. Apache).
It should be possible to have "branches" as the next level of configuration in JIRA. A project manager should be able to lock down (aka. freeze) branches and open them later again.
Nov 05, 2007
Stephen says:
We currently don't feel the need to apply different policies to different parts ...We currently don't feel the need to apply different policies to different parts of the repository. Policies are set on a per project basis, and each project has its own repository. If there is a genuine need for different policies to be applied to parts of the repository, then this is not JIRA specific and your efforts would be better spent addressing the root cause (subversion's application of triggers).
We would, however, benefit from tighter control over the allowed workflow states. Presumably this could then be used to prevent programmers checking in code which hasn't yet been authorised by budget holders, or flagged as in progress, etc.
Nov 06, 2007
Ferenc Kiss says:
We would, however, benefit from tighter control over the allowed workflow states...Hey Stephen, could you give more details what additional rules would you need for this?
Nov 08, 2007
Stephen says:
Rather than just specifying issues must be "unresolved" it would be nice to choo...Rather than just specifying issues must be "unresolved" it would be nice to choose multiple workflow states from the workflow assigned to the project. We currently don't have a custom workflow (as I'm not sure this would currently give us any benefit) but if the commit acceptance plugin supported it, I could see that we might have an initial open and then a verified/approved state. As an admin it would be nice to then allow only the approved, verified and in-progress states to support repository commitals. I presume there are workflow security models to only allow managers to transision issues to the approved state, hence preventing programers from adding features for the sake of it?
Feb 08
Michael Croft says:
yes! We're considering a workflow specific to our Scrum process, so our terms do...yes! We're considering a workflow specific to our Scrum process, so our terms don't match the default workflow.
Nov 06, 2007
Gunnar Wagenknecht says:
We currently don't feel the need to apply different policies to different parts ...I partially disagree. Hosting each project in its own repository is a choice that your organization made. It might fit your use-case and requirements very well. However, there are also organization which use the single repository model where all projects are hosted in on Subversion repository. This as some advantages but those are out of scope here. The Apache Foundation is a prominent user of the one repository model.
I agree that it is not JIRA's task to take care of it. But it's also not the task of Subversion. It's the task of the "glue" component between both and that's this plug-in. Whether the paths are evaluated at the Subversion side, i.e. inside the hooks or whether the complete list of changed paths is transfered to the JIRA server and evaluated there is probably just an implementation detail.
Nov 06, 2007
Gunnar Wagenknecht says:
Hey, what's the status for this? I already asked on the JIRA issue but didn't ge...Hey, what's the status for this? I already asked on the JIRA issue but didn't get an answer. We desperately need a lot features discussed here and I'd be able to help with the implementation.
Nov 07, 2007
Ferenc Kiss says:
Hey Gunnar, I'm sorry for not answering your questions (I thought I answered it ...Hey Gunnar, I'm sorry for not answering your questions (I thought I answered it somewhere in JIRA...).
Anyway, the thing is that currently we're not actively working on the 2.x branch, as the feedback we received so far was not enough to make proper decisions yet (and we are busy with others). But please drop me a mail to ferenc.kiss at midori dot hu, tell me what exact feature you'd need and there is chance that it could get into the next 1.x release maybe. (Especially if you can help with the implementation
).
Nov 10, 2007
John Allen says:
Ferenc, more than happy re the planned scope of 2.0. You may wish to consider a ...Ferenc, more than happy re the planned scope of 2.0.
You may wish to consider a connectors approach to handle the mapping of the various VCS domain models to the common one required by the plugin.
p.s. I think it would be worth while promoting this page a little more prominently on the plugin's home page to get more feedback.
Dec 02, 2007
Jason Harris says:
it would be useful to support rules based on the target version of the Jira issu...it would be useful to support rules based on the target version of the Jira issue. For example, for the product I develop I have a branch for each major customer release (e.g. branches/rel_1.1.0, etc). In order to enforce better release control I'd like to be able to limit the commits on that branch to Jira issues that have a particular fix release (e.g 1.1.1). It isn't enough that the commit is against a Jira issue from a particular project, there are cases where you want to limit the commits to be a given subset of open issues.
It would be nice if you could also do this based on the component specified in the Jira issue (or even an arbitrary set of isssue fields) , but the important one for me is the Jira issue's target version