Commit messages outside of try should NOT trigger try syntax parser



Task Configuration
4 months ago
4 months ago


(Reporter: Tomcat, Unassigned, Mentored)






4 months ago
The landing of broke the decision task like

File "/home/worker/checkouts/gecko/taskcluster/taskgraph/", line 208, in parse_message
[task 2017-06-23T07:03:35.174232Z]     parts = split_try_msg(message)
[task 2017-06-23T07:03:35.174267Z]   File "/home/worker/checkouts/gecko/taskcluster/taskgraph/", line 204, in split_try_msg
[task 2017-06-23T07:03:35.174297Z]     return shlex.split(escape_whitespace_in_brackets(message))
[task 2017-06-23T07:03:35.174325Z]   File "/usr/lib/python2.7/", line 279, in split
[task 2017-06-23T07:03:35.214862Z]     return list(lex)
[task 2017-06-23T07:03:35.214933Z]   File "/usr/lib/python2.7/", line 269, in next
[task 2017-06-23T07:03:35.215004Z]     token = self.get_token()
[task 2017-06-23T07:03:35.215049Z]   File "/usr/lib/python2.7/", line 96, in get_token
[task 2017-06-23T07:03:35.215080Z]     raw = self.read_token()
[task 2017-06-23T07:03:35.215149Z]   File "/usr/lib/python2.7/", line 172, in read_token
[task 2017-06-23T07:03:35.215190Z]     raise ValueError, "No closing quotation"

but since this was not a try push and a production push this should not trigger try syntax parser. In other words, for some reason the try syntax parser is running outside of try ?
I think this came from bug 1333167, where we have arguments passed to try before we decide which target_task_method to use.

Interestingly, usually commit hooks will prevent something like this from being committed, so there must be some difference in how the commit hook looks for `try:` and how the in-tree stuff does.  Maybe the fix is just to adjust those to match.  Maybe it's as simple as `\<try:` or the equivalent for the chose regexp engine?

The other option is to add a parameter, say `try_syntax`, which is set to True for try-like branches (yes, we have had more than one from time to time). Then the syntax parser could just short-circuit when that parameter was false.

This is relatively low-priority, and would make a good starter bug for hacking on the taskgraph generation.
Component: General → Task Configuration
Keywords: good-first-bug

Comment 2

4 months ago
1 failures in 892 pushes (0.001 failures/push) were associated with this bug in the last 7 days.   

Repository breakdown:
* mozilla-inbound: 1

Platform breakdown:
* gecko-decision: 1

For more details, see:
You need to log in before you can comment on or make changes to this bug.