1375786 - Commit messages outside of try should NOT trigger try syntax parser

Status: RESOLVED FIXED

(Firefox Build System :: Task Configuration, task)

Description

[Carsten Book [:Tomcat]]

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 ?

Comment 1

[Dustin J. Mitchell [:dustin] (he/him)]

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.

Comment 2

[Intermittent Failures Robot]

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

Comment 3

[Dustin J. Mitchell [:dustin] (he/him)]

Brian may have fixed this. I will investigate.

Comment 4

[Dustin J. Mitchell [:dustin] (he/him)]

Yes, this is fixed; try syntax is only consulted for try branches

    if 'try' in project:

it's not the best way of detecting a try branch, but it works..