Feature #286
closed
I already use a similar feature with trac.
When a commit message contains a term like "close",
"fix", "ref", "see" with a ticket
(issue in redMine) number (or several), the relevant tickets
are updated in a sensible way.
e.g. "closes 141" closes issue 141, "ref 233"
put a comment on issue 233, etc...
Usually comments reports the full svn comment.
Trac's post-commit hook is available
at http://trac.edgewall.org/browser/trunk/contrib/trac-post-commi
t-hook
Sounds even better, and we have BSD-licensed code we can base
it off of. I
might look at tackling this and submitting a patch at some point,
unless
someone else beats me to it. :)
Well, the main problem i see is that they use trac directly as
in the current version trac and the repository trac is bound
to must reside on the same host.
As we can refer to remote repository, we must consider a remote
interface with all the security concerns it brings.
Probably using ActionWebService to model a sensible interface
to expose (maybe to other.. for example to continuous build systems,
which will be my next proposal) the relevant operations and then
build the hook using this will be the best thing (maybe Jean-Philippe
has already planned some kind of remote interface).
Maybe i'll have some time during the we to look into this and,
of course, i'll be glad to help with the implementation
I would not recommend using AWS - it is overly complicated and
generally
annoying to work with. I would look at either using simple GET/POST
methods with form-style encoding, or creating a REST-style
interface.
As far as security, you would probably just generate an "API
key" to give to
the post-commit script. This would be one of the parameters you
would pass
to the API.
Lastly, you would probably need to deal with matching Subversion
usernames
to RedMine users if you want to accurately say which user did
what. This is
probably something you would have to add to the RedMine user
form.
Good advice, i write AWS, but only as an example as i never use
it directly. Maybe the REST interface is the best one.
As far as security, i'll consider to allow only some specific
hosts (e.g. only the local network for a internet-exposed instance)
, use a security key or both as a minimum set of features.
Thinking about users, i think that defining multiple external
services and defining user mapping on these wuold be better than
hooking into the user form (and "polluting" it).
Just adding my 2 cents...
It would be preferable to stay away from Subversion specific
features such as post-commit hooks as a permanent solution.
There are already another feature request asking for CVS support,
but with the rise in usage and popularity of distributed SCMs
(eg, GIT, SVK, Darcs), it can't be guaranteed that features like
post-commit hooks will be available.
Trac scans the repository logs every X minutes, and imports the
changeset details into it's own database as a cache. I would
prefer if redMine was doing this too, as it would allow us to
interrogate the changeset comments for issue numbers and link
it to the issue(s). Jira has an SVN plugin that does just this,
except that it does not cache the changesets in it's own database
unless the changeset refers to an issue.
Anyway, post-commit hooks are something that could be done now
without any changes to redMine.
Just adding my 2 cents. I personally feed that Redmine is quite superior to Jira and Bugzilla. However, a lot of software, such as Teamcity, Cruise Control all support integration with Bugzilla. Given that the Bugzilla RPC api is widely accepted, are there any plans to implement a Buzilla RPC compliant adapter into Redmine? I think this would help with acceptance of redmine into enterprise operations such as ours.
Thanks,
Todd
Sorry, delete these 2 notes, I added it to the wrong issue. See #4798
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by