The landing of https://hg.mozilla.org/integration/mozilla-inbound/rev/aa1693a26a15eb5cba24102222687dc81eeddd7b broke the decision task like https://treeherder.mozilla.org/logviewer.html#?job_id=109486618&repo=mozilla-inbound&lineNumber=103 File "/home/worker/checkouts/gecko/taskcluster/taskgraph/try_option_syntax.py", 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/try_option_syntax.py", 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/shlex.py", 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/shlex.py", 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/shlex.py", 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/shlex.py", 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.
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: https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1375786&startday=2017-06-19&endday=2017-06-25&tree=all