commit_updater will not capture commands at the end of a commit message.

[Amar Takhar <tracticket@…>]

If you have:

This is a test #123.

Everything works fine, however:

This is a test #123

Will not work. There has to be an extra character after the command. This may seem trivial however it's easy to get caught by ending your sentence then adding the command. I looked at the RE it works fine (tested) so the bug is probably somewhere else.

Any hints would be great, I did a cursory look and did not find the issue.

[Ryan J Ollos]

You must have the following in your configuration:

[ticket]
commit_ticket_update_commands.refs = <ALL>

I'm not able to reproduce the issue. What are your other [ticket] commit_ticket_update_* settings?

You've selected 1.0dev as your version. Are you running the latest 1.0-stable, or a pre-1.0 release of Trac?

[Amar Takhar <tracticket@…>]

The settings are:

commit_ticket_update_envelope =
commit_ticket_update_commands.close = close, closed, closes, fix, fixed, fixes
commit_ticket_update_commands.refs = addresses, references, refs, see, address, update, updates
commit_ticket_update_check_perms = false
commit_ticket_update_notify = yes

I added the commit_ticket_update_commands.refs = <ALL> you suggested above just now. I have yet to test if it makes a difference.

Here are some example commits showing the issue for us, this one works:

​http://trac.buildbot.net/changeset/5e319abcc68b6a4de43313c251d6575d50e0c74d

​http://trac.buildbot.net/ticket/2814#comment:3

These did not:

​http://trac.buildbot.net/changeset/eb835f94a581b72b2be7ebdd2a0467f48ff8c3b7

​http://trac.buildbot.net/changeset/12736674f7d1cf65081debac88e708d0544076a5

The only difference between the two is the lack of a period at the end. As long as there is an extra character of any type it catches the command. I'll run a test with the "<ALL>" added to see what happens.

[Amar Takhar <tracticket@…>]

So, we ran a test. Adding <ALL> did update the ticket.

However, does this simply update all tickets when referencing a #[0-9]? I haven't looked at the source. We use Github for the repository itself. It would be very annoying to have random tickets updating when referencing a pull request.

It should work without having <ALL> though, somewhere in the code it's looking for something after a command, I could not spot it is there a reason why it is this way? The RE used does not have this requirement.

Thanks for taking the time to look at this, it's caused a lot of (random) grief. :)

[Ryan J Ollos]

Replying to Amar Takhar <tracticket@…>:

I added the commit_ticket_update_commands.refs = <ALL> you suggested above just now. I have yet to test if it makes a difference.

It wasn't a suggestion, it was a statement based on the example you provided. The example commit message This is a test #123 doesn't have a command keyword. I should rephrase my comment:1 as: Given the information you provided, it must be true that you have the following in your configuration.

If you use command keywords in your message then you won't want to use <ALL>.

[Ryan J Ollos]

Here's a case where the changeset message exists in the ticket, but the command doesn't end with a period:

• ​http://trac.buildbot.net/changeset/0c0681b7551f0d1b99b1e32fafff44b8f0a094d1
• ​http://trac.buildbot.net/ticket/2814#comment:6

Here is a case where the command ends with a period, but the reference is not present in the ticket:

• ​http://trac.buildbot.net/changeset/1673fac02c0a06fe2e856b1f8e8b52ae6ff2151a
• ​http://trac.buildbot.net/ticket/2814

It appears that some other factor is determining whether the references are inserted.

• Which version of Trac are you running?
• What is the content of your post-receive script?
• Have you looked at the logs with log level debug for a case that it fails? That would allow you to confirm that commit_updater is being called. Example:

  2014-05-30 07:03:52,826 Trac[api] DEBUG: Event changeset_added on repository 'tracdev' for revision '47'
  2014-05-30 07:03:52,829 Trac[commit_updater] DEBUG: Updating ticket #1
  

[Amar Takhar <tracticket@…>]

Replying to rjollos:

It wasn't a suggestion, it was a statement based on the example you provided. The example commit message This is a test #123 doesn't have a command keyword. I should rephrase my comment:1 as: Given the information you provided, it must be true that you have the following in your configuration.

Argh, that was a typo I meant to add [command] as a replaceable in front of the ticket number. Unfortunately I'm unable to edit ticket descriptions.

[Amar Takhar <tracticket@…>]

Replying to rjollos:

It appears that some other factor is determining whether the references are inserted.

Yes, that's what I thought as well since the RE is fine.

• Which version of Trac are you running?
• What is the content of your post-receive script?
• Have you looked at the logs with log level debug for a case that it fails? That would allow you to confirm that commit_updater is being called. Example:

  2014-05-30 07:03:52,826 Trac[api] DEBUG: Event changeset_added on repository 'tracdev' for revision '47'
  2014-05-30 07:03:52,829 Trac[commit_updater] DEBUG: Updating ticket #1
  

• Trac-1.0.2dev_r12767-py2.7 on FreeBSD 10.
• I'm using ​https://github.com/aaugustin/trac-github
• No, I haven't but I will do that ASAP.

[Ryan J Ollos]

Replying to Amar Takhar <tracticket@…>:

• I'm using ​https://github.com/aaugustin/trac-github

Cool, I wasn't familiar with that project.

I just skimmed over the README and spotted ​known issues, which sounds similar to what you are experiencing.

[Ryan J Ollos]

You may want to follow up on the ​this mailing list thread about trac-github integration.

[Amar Takhar <tracticket@…>]

Replying to rjollos:

Replying to Amar Takhar <tracticket@…>:

• I'm using ​https://github.com/aaugustin/trac-github

Cool, I wasn't familiar with that project.

I just skimmed over the README and spotted ​known issues, which sounds similar to what you are experiencing.

It's not the same issue, this same problem exists with local scripts, as well. The local trac API is used to deliver messages.

My problem is not about updating a repo or notifications. It's specifically related to a ticket update when the command is the last item in the description with no extra characters after the ticket number.

[Amar Takhar <tracticket@…>]

Replying to rjollos:

You may want to follow up on the ​this mailing list thread about trac-github integration.

We've never had a problem with the Github plugin it's always worked fine. The one I linked to is updated for the latest Github webhook API.

[Ryan J Ollos]

Replying to Amar Takhar <tracticket@…>:

It's not the same issue, this same problem exists with local scripts, as well.

I cannot reproduce the issue, so I'm inclined to think your issue is caused by a plugin, or an InstallationIssue. Looking at the logs like I suggested should reveal more insight.

My problem is not about updating a repo or notifications. It's specifically related to a ticket update when the command is the last item in the description with no extra characters after the ticket number.

In comment:6 I showed cases in which the tickets were not being updated even when there were characters after the ticket number. I doubt the issue is due to CommitTicketUpdater failing to parse the ticket reference from the commit message. I am even less convinced that it has anything to do with the message not having any characters after the ticket reference (and you seemed to agree in comment:8). If you still believe this, how can you explain the cases shown in comment:6?

You should try executing your post-receive hook from the command line, passing in a changeset hash for a case in which the message didn't get inserted, and another case in which the message did get inserted.

[Amar Takhar <tracticket@…>]

Replying to rjollos:

I cannot reproduce the issue, so I'm inclined to think your issue is caused by a plugin, or an InstallationIssue. Looking at the logs like I suggested should reveal more insight.

Yep, I will be doing the log check when the hook posts as per your suggestion this week.

In comment:6 I showed cases in which the tickets were not being updated even when there were characters after the ticket number. I doubt the issue is due to CommitTicketUpdater failing to parse the ticket reference from the commit message. I am even less convinced that it has anything to do with the message not having any characters after the ticket reference (and you seemed to agree in comment:8). If you still believe this, how can you explain the cases shown in comment:6?

Ah, actually that worked because I applied your suggestion. Look at the time those commits happened: it was after you suggested adding <ALL>. This is when we realised it simply scans the entire message for #[0-9] and updates any ticket.

You should try executing your post-receive hook from the command line, passing in a changeset hash for a case in which the message didn't get inserted, and another case in which the message did get inserted.

I will try that and report back, thanks!

[Christian Boos]

No feedback, closing.