Performing actions on commit messages
One of the main things we wanted to do with the subversion integration is add the ability to perform custom actions. Any thoughts on what you want exactly? Here are some ideas:
- @[closes #15]@ - closes ticket #15.
- @[committed #15]@ - adds custom tag if the keyword isn't @/close|resolve|hold|invalid/@
- @[#15 -> rick]@ assign?
Another idea that I'm liking more is just borrowing the search keywords:
- @[#15 state:hold tag:committed]@
Some other ideas...
Discussions are closed to public comments.
If you need help with Lighthouse please
start a new discussion.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
1 Posted by Don on 05 Apr, 2007 12:02 AM
I haven't set up the SVN integration to see how it works now, but... I'd definitely see a use for the ability to add a comment to a specific issue via the commit message. No matter how good you are, sometimes you need to commit something that might help an issue, but not clear it up completely. Like if I had a ticket regarding some formatting issues for IE5, Opera, and Netscape Communicator Gold Beta 1...
*[comment #15]Fixed formatting for modern browsers, still broken in Communicator
(just ignore that asterisk, I'm a formatting moron apparently)
I can't close the ticket yet, but at least I can update it to let everybody know that my formatting is now good in browsers from this century. You can't really take a subversion commit and resolve which lighthouse user it is for certain, but I don't think that's a big deal.
2 Posted by Rick on 05 Apr, 2007 12:19 AM
Someone else IMed me the same suggestion. Though perhaps that's just automatic. As in, if you reference a ticket number at all it updates it w/ the full text of the commit message.
3 Posted by Rick on 04 May, 2007 06:19 PM
Just committed this. I went with my last idea. Just have a string like [#23 ...]. The available keywords (responsible, state, tagged, and milestone) work just like the search keywords.
Here are a couple example log messages:
bq. add widget model [#15]
bq. add widget controller [#15 tagged:committed]
A couple caveats:
The ticket numbers only work in the project that the changesets post to.
The ticket's updater is the user of the token used in the svn post commit hook. You could modify the post commit script to use a different token based on the svn username, however.
4 Posted by jlee (at lsu) on 29 Oct, 2008 03:44 PM
When I commit using the lighthouse.rb script, my message is as follows:
Adding more comments to test ticket closure. [#3 tagged:committed state:resolved responsible:jlee milestone:none]
Lighthouse puts this in ticket #3:
(from [170]) Adding more comments to test ticket closure. [#3 tagged:committed state:resolved responsible:jlee milestone:none]
The tag is added; however the state is not changed to resolved (from new). I know it is seeing the info because it is adding the tag. Any ideas?
5 Posted by Rick on 01 Nov, 2008 12:31 AM
There was a bug with the command parser where it ignored every other command if the
taggedcommand was present. I deployed a fix to it this morning, so it should work from now on.Also, you should be able to reference multiple tickets now:
fixed stuff [\#1 \#2 state:resolved]orfixed stuff [\#1 state:resolved] [\#2 state:resolved tagged:foo].Disregard the \'s. The parser was converting those into links to other Voxpop discussions.
6 Posted by jlee (at lsu) on 04 Nov, 2008 03:53 PM
I attempted to use the following:
but it did not work as expected. Ticket #50 was not changed. When I used both tickets were changed properly. While this works well enough, I thought I'd point it out. Thanks for fixing the problem, it will save a lot of time on my end.7 Posted by Rick on 05 Nov, 2008 02:13 AM
Oh, part of it hasn't been deployed yet. Sorry for the trouble. I have some other cool API stuff coming out that require some database migrations. I didn't want to jinx it by deploying it right before Rubyconf. Expect some awesome API news next week :)