89161 2012-06-14 20:03:49 -0700 Support new format for test expectations 2012-09-19 19:06:59 -0700 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED NRWT P2 Normal --- 94545 94557 94632 94638 96569 96588 1 rniwa dpranke abarth benjamin darin dglazkov dpranke gyuyoung.kim mjs ojan pkasting tony oldest_to_newest 649799 0 rniwa 2012-06-14 20:03:49 -0700 Support new format for test expectations 649804 1 147716 rniwa 2012-06-14 20:14:30 -0700 Created attachment 147716 Patch 649807 2 rniwa 2012-06-14 20:20:25 -0700 This patch is missing some pieces. e.g. garden-o-matic should be able to generate test expectations using new format, and flakiness dashboard also needs to support new format. I'm intending to update those tools in follow up patches. 649813 3 147716 abarth 2012-06-14 20:45:44 -0700 Comment on attachment 147716 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=147716&action=review > Tools/ChangeLog:11 > + It replaces BUGWK12345, BUGCR67890, and BUGRNIWA by webkit.org/12345, crbug.com/67890, and Bug(rniwa), webkit.org/12345 <-- not webkit.org/b/12345 ? 649816 4 ojan 2012-06-14 20:51:17 -0700 (In reply to comment #2) > This patch is missing some pieces. e.g. garden-o-matic should be able to generate test expectations using new format, and flakiness dashboard also needs to support new format. I'm intending to update those tools in follow up patches. I'm not really a fan of breaking these tools for more than a couple hours. People depend on these. I'd rather you break the patch up by changing one bit at a time (e.g. uppercase->camelCase in one patch, BUGWK->urls in another, etc) and keep all the tools working. Also, I think it's just easier to reason about the patch if it's only changing one of those things at a time. There's no benefit to doing this in one big patch. 649828 5 rniwa 2012-06-14 21:15:24 -0700 (In reply to comment #4) > (In reply to comment #2) > > This patch is missing some pieces. e.g. garden-o-matic should be able to generate test expectations using new format, and flakiness dashboard also needs to support new format. I'm intending to update those tools in follow up patches. > > I'm not really a fan of breaking these tools for more than a couple hours. My plan is make this change, fix those tools, and then convert test expectations. i.e. I don't intend on converting test expectations until I patch other tools. I wanted to land this patch first so that people can experiment with new format. > People depend on these. I'd rather you break the patch up by changing one bit at a time (e.g. uppercase->camelCase in one patch, BUGWK->urls in another, etc) and keep all the tools working. I don't think that's realistic because things like flakiness dashboard can't be updated synchronously. > Also, I think it's just easier to reason about the patch if it's only changing one of those things at a time. There's no benefit to doing this in one big patch. There is a big benefit that tools will be broken at most once, not 4-5 times. 650495 6 147716 dpranke 2012-06-15 14:14:50 -0700 Comment on attachment 147716 Patch Thanks for working on this! Note that this probably duplicates bug 86796, so we should close one or the other (probably that one). (In reply to comment #2) > This patch is missing some pieces. e.g. garden-o-matic should be able to generate test expectations using new format, and flakiness dashboard also needs to support new format. I'm intending to update those tools in follow up patches. I don't think the flakiness dashboard actually looks at the test expectations syntax. We do need to make garden-o-matic work as part of this; it should be easy to do. On the other hand, I don't think I agree with Ojan that we should change the syntax in steps. That will just be really confusing over the course of the transition and I shudder to think of the merge conflicts that might arise. I'm a big-bang fan. Go bigger! (Actual patch comments): View in context: https://bugs.webkit.org/attachment.cgi?id=147716&action=review > Tools/ChangeLog:17 > + Finally, comments start with # instead of //. I don't recall agreeing on changing the comment delimiter, but whatever :) > Tools/Scripts/webkitpy/layout_tests/run_webkit_tests_integrationtest.py:261 > + port_obj.expectations_dict = lambda: {'': 'a # syntax error'} nit: I'd probably get rid of the '#' here since it might be confusing. It was not the intent of this test for '# syntax error' to represent a comment in any way. > Tools/Scripts/webkitpy/layout_tests/models/test_expectations.py:271 > + elif modifier.lower().startswith('bug') or '/' in modifier: just checking if '/' is in the modifier is probably a bit fast-and-loose for me, since it would allow 'foo/bar' to be legal. > Tools/Scripts/webkitpy/layout_tests/models/test_expectations.py:339 > + I would rather we not try to match this all as a single regex, since it looks like gibberish to me :) Can we split this into old-style match and new-style match and figure out which one to use? "description" does not seem like a great name to me; I'd probably use 'bugid' to be consistent with the variable names. 'platforms' is not the right name, since it can include things like 'release' and 'debug' and presumably things like 'qt-4.8' and 'wk2' and gpu/cpu. Also, you need to update the docstring in _tokenize() Lastly, since this is line-by-line, I'm guessing it will allow you to mix the two syntaxes in the file. I realize this is just a transitional thing, but I'm not sure if I like that. In particular it's hard for me to judge the correctness of this and it's hard to tell what the post-transition code would look like. Maybe it would help to post a version of the code that will only parse the new syntax? > Tools/Scripts/webkitpy/layout_tests/models/test_expectations.py:389 > + # FIXME: Should we support rebaseline modifier at all? Yes, we still need to support REBASELINE, but I've been saying it would move to the expectations (and no longer be a modifier) > Tools/Scripts/webkitpy/layout_tests/models/test_expectations.py:397 > + expectation_line.warnings.append("WontFix should not be used with any other expectation") I don't think we need to enforce this; I seem to recall arguing that skip and wontfix should be handled identically. 650538 7 rniwa 2012-06-15 14:53:29 -0700 (In reply to comment #6) > (From update of attachment 147716 [details]) > Thanks for working on this! Note that this probably duplicates bug 86796, so we should close one or the other (probably that one). I think we can make this bug a blocker instead because we'll need to fix garden-o-matic as well. > (In reply to comment #2) > > This patch is missing some pieces. e.g. garden-o-matic should be able to generate test expectations using new format, and flakiness dashboard also needs to support new format. I'm intending to update those tools in follow up patches. > > I don't think the flakiness dashboard actually looks at the test expectations syntax. We do need to make garden-o-matic work as part of this; it should be easy to do. It does in javascript. It fetches TextExpectations via XHR and shows expectations. > > Tools/Scripts/webkitpy/layout_tests/run_webkit_tests_integrationtest.py:261 > > + port_obj.expectations_dict = lambda: {'': 'a # syntax error'} > > nit: I'd probably get rid of the '#' here since it might be confusing. It was not the intent of this test for '# syntax error' to represent a comment in any way. Will do. > > Tools/Scripts/webkitpy/layout_tests/models/test_expectations.py:271 > > + elif modifier.lower().startswith('bug') or '/' in modifier: > > just checking if '/' is in the modifier is probably a bit fast-and-loose for me, since it would allow 'foo/bar' to be legal. On the other hand, we don't want to do a full URL/URI match either. Also, I don't think we want to whitelist URLs because we want to be able to use URLs of Skia, V8, etc... issue trackers. > > Tools/Scripts/webkitpy/layout_tests/models/test_expectations.py:339 > > + > > I would rather we not try to match this all as a single regex, since it looks like gibberish to me :) Can we split this into old-style match and new-style match and figure out which one to use? A big advantage of using a regular expression here is so that the said javascript code in flakiness dashboard can use the regular expression. > "description" does not seem like a great name to me; I'd probably use 'bugid' to be consistent with the variable names. But that's not accurate because we allow things like Bug(rniwa). Also webkit.org/b/12345 isn't really a bug id. Maybe bug_info? > 'platforms' is not the right name, since it can include things like 'release' and 'debug' and presumably things like 'qt-4.8' and 'wk2' and gpu/cpu. How about configurations? It's definitely not modifiers. > In particular it's hard for me to judge the correctness of this and it's hard to tell what the post-transition code would look like. Maybe it would help to post a version of the code that will only parse the new syntax? In the post transition, we'll get rid of the statements after the if. > > Tools/Scripts/webkitpy/layout_tests/models/test_expectations.py:389 > > + # FIXME: Should we support rebaseline modifier at all? > > Yes, we still need to support REBASELINE, but I've been saying it would move to the expectations (and no longer be a modifier) Okay, so just remove this FIXME? > > Tools/Scripts/webkitpy/layout_tests/models/test_expectations.py:397 > > + expectation_line.warnings.append("WontFix should not be used with any other expectation") > > I don't think we need to enforce this; I seem to recall arguing that skip and wontfix should be handled identically. If WontFix and Skip are synonymous, then we certainly don't want other expectations to be there, right? 650554 8 dpranke 2012-06-15 15:04:41 -0700 (In reply to comment #7) > (In reply to comment #6) > > (From update of attachment 147716 [details] [details]) > > Thanks for working on this! Note that this probably duplicates bug 86796, so we should close one or the other (probably that one). > > I think we can make this bug a blocker instead because we'll need to fix garden-o-matic as well. > Well, I want you to fix garden-o-matic as a part of this, if we can. Can you work up a patch that does that so we can see if it adds much complexity or not? > > (In reply to comment #2) > > > This patch is missing some pieces. e.g. garden-o-matic should be able to generate test expectations using new format, and flakiness dashboard also needs to support new format. I'm intending to update those tools in follow up patches. > > > > I don't think the flakiness dashboard actually looks at the test expectations syntax. We do need to make garden-o-matic work as part of this; it should be easy to do. > > It does in javascript. It fetches TextExpectations via XHR and shows expectations. > I see. I believe I've had conversations w/ Ojan where we need to stop this and probably just embed the appropriate text into the uploaded json file (or do something else). Especially with cascading expectations, getting this right gets harder and harder, duplicating more and more code. Maybe we need to fix that before landing this. > > > Tools/Scripts/webkitpy/layout_tests/models/test_expectations.py:271 > > > + elif modifier.lower().startswith('bug') or '/' in modifier: > > > > just checking if '/' is in the modifier is probably a bit fast-and-loose for me, since it would allow 'foo/bar' to be legal. > > On the other hand, we don't want to do a full URL/URI match either. Also, I don't think we want to whitelist URLs because we want to be able to use URLs of Skia, V8, etc... issue trackers. > I understand, but this is too loose. maybe look for at least something that looks like a domain name (.com/.org?) followed by a slash and ends in a number? > > > Tools/Scripts/webkitpy/layout_tests/models/test_expectations.py:339 > > > + > > > > I would rather we not try to match this all as a single regex, since it looks like gibberish to me :) Can we split this into old-style match and new-style match and figure out which one to use? > > A big advantage of using a regular expression here is so that the said javascript code in flakiness dashboard can use the regular expression. > good point, however, cf. above :) Do javascript regexps actually let you name subpattern matches? > > "description" does not seem like a great name to me; I'd probably use 'bugid' to be consistent with the variable names. > > But that's not accurate because we allow things like Bug(rniwa). Also webkit.org/b/12345 isn't really a bug id. Maybe bug_info? > I didn't realize bugid had an actual definition :) If you prefer bug_info that's fine, or bug_token, or bug, or something. > > 'platforms' is not the right name, since it can include things like 'release' and 'debug' and presumably things like 'qt-4.8' and 'wk2' and gpu/cpu. > > How about configurations? It's definitely not modifiers. > configurations works for me. > > In particular it's hard for me to judge the correctness of this and it's hard to tell what the post-transition code would look like. Maybe it would help to post a version of the code that will only parse the new syntax? > > In the post transition, we'll get rid of the statements after the if. Which 'if'? Also, the regex changes as well, right? > > > > Tools/Scripts/webkitpy/layout_tests/models/test_expectations.py:389 > > > + # FIXME: Should we support rebaseline modifier at all? > > > > Yes, we still need to support REBASELINE, but I've been saying it would move to the expectations (and no longer be a modifier) > > Okay, so just remove this FIXME? > Yes. > > > Tools/Scripts/webkitpy/layout_tests/models/test_expectations.py:397 > > > + expectation_line.warnings.append("WontFix should not be used with any other expectation") > > > > I don't think we need to enforce this; I seem to recall arguing that skip and wontfix should be handled identically. > > If WontFix and Skip are synonymous, then we certainly don't want other expectations to be there, right? I believe I've said before that I'm okay with other expectations being there (although not required), since it can be useful for when you run with --force/--skipped=only to see if tests are doing something different than what you expected). 650581 9 rniwa 2012-06-15 15:38:07 -0700 (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > (From update of attachment 147716 [details] [details] [details]) > > > Thanks for working on this! Note that this probably duplicates bug 86796, so we should close one or the other (probably that one). > > > > I think we can make this bug a blocker instead because we'll need to fix garden-o-matic as well. > > > > Well, I want you to fix garden-o-matic as a part of this, if we can. Can you work up a patch that does that so we can see if it adds much complexity or not? I guess we can try that. > > > > Tools/Scripts/webkitpy/layout_tests/models/test_expectations.py:271 > > > > + elif modifier.lower().startswith('bug') or '/' in modifier: > > > > > > just checking if '/' is in the modifier is probably a bit fast-and-loose for me, since it would allow 'foo/bar' to be legal. > > > > On the other hand, we don't want to do a full URL/URI match either. Also, I don't think we want to whitelist URLs because we want to be able to use URLs of Skia, V8, etc... issue trackers. > > > > I understand, but this is too loose. maybe look for at least something that looks like a domain name (.com/.org?) followed by a slash and ends in a number? Match r"(\w+\.\w+/)" ? > > > > Tools/Scripts/webkitpy/layout_tests/models/test_expectations.py:339 > > > > + > > > > > > I would rather we not try to match this all as a single regex, since it looks like gibberish to me :) Can we split this into old-style match and new-style match and figure out which one to use? > > > > A big advantage of using a regular expression here is so that the said javascript code in flakiness dashboard can use the regular expression. > > > > good point, however, cf. above :) Do javascript regexps actually let you name subpattern matches? I don't think it does name sub-pattern matches, or support verbose mode. However, that's much better not being able to share any logic at all. > > > In particular it's hard for me to judge the correctness of this and it's hard to tell what the post-transition code would look like. Maybe it would help to post a version of the code that will only parse the new syntax? > > > > In the post transition, we'll get rid of the statements after the if. > > Which 'if'? Also, the regex changes as well, right? The if that wraps all the code I'm adding in _tokenize_line. > > > > Tools/Scripts/webkitpy/layout_tests/models/test_expectations.py:397 > > > > + expectation_line.warnings.append("WontFix should not be used with any other expectation") > > > > > > I don't think we need to enforce this; I seem to recall arguing that skip and wontfix should be handled identically. > > > > If WontFix and Skip are synonymous, then we certainly don't want other expectations to be there, right? > > I believe I've said before that I'm okay with other expectations being there (although not required), since it can be useful for when you run with --force/--skipped=only to see if tests are doing something different than what you expected). Okay, will remove it for now then. 650636 10 dpranke 2012-06-15 17:09:14 -0700 (In reply to comment #9) > Match r"(\w+\.\w+/)" ? maybe with .*\d+ on the end but I'm not too picky. 653985 11 dpranke 2012-06-20 16:25:29 -0700 *** Bug 86796 has been marked as a duplicate of this bug. *** 653987 12 dpranke 2012-06-20 16:26:42 -0700 for the record, see old discussion in https://bugs.webkit.org/show_bug.cgi?id=86796 that led up to this (also some threads on webkit-dev that I'm too lazy to link to right now). 654530 13 147716 ojan 2012-06-21 08:04:38 -0700 Comment on attachment 147716 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=147716&action=review >>>>> Tools/Scripts/webkitpy/layout_tests/models/test_expectations.py:271 >>>>> + elif modifier.lower().startswith('bug') or '/' in modifier: >>>> >>>> just checking if '/' is in the modifier is probably a bit fast-and-loose for me, since it would allow 'foo/bar' to be legal. >>> >>> On the other hand, we don't want to do a full URL/URI match either. Also, I don't think we want to whitelist URLs because we want to be able to use URLs of Skia, V8, etc... issue trackers. >> >> I understand, but this is too loose. maybe look for at least something that looks like a domain name (.com/.org?) followed by a slash and ends in a number? > > Match r"(\w+\.\w+/)" ? Lets be more strict about it. Bugs should start with one of the following: bug crbug.com webkit.org/b I don't think we should allow the longform URLS or the http(s)://. If other ports have other bug database URLS they want to add, they can extend the list of valid prefixes (e.g. rdar://) 654622 14 rniwa 2012-06-21 09:56:11 -0700 (In reply to comment #13) > (From update of attachment 147716 [details]) > Lets be more strict about it. Bugs should start with one of the following: > bug > crbug.com > webkit.org/b Why? What's the benefit in doing that? It'll be annoying having to modify test running scripts just to use new URL. It's both counter-intutitive and counter-productive. 655434 15 ojan 2012-06-22 07:14:49 -0700 (In reply to comment #14) > (In reply to comment #13) > > (From update of attachment 147716 [details] [details]) > > Lets be more strict about it. Bugs should start with one of the following: > > bug > > crbug.com > > webkit.org/b > > Why? What's the benefit in doing that? It'll be annoying having to modify test running scripts just to use new URL. It's both counter-intutitive and counter-productive. It helps people not make typos, e.g. the linter will catch if you type webkit.org/1234, which is a very common mistake. Also, I don't think we should allow the longform URLs as it would decrease the readability of the file. 655492 16 rniwa 2012-06-22 09:05:49 -0700 (In reply to comment #15) > It helps people not make typos, e.g. the linter will catch if you type webkit.org/1234, which is a very common mistake. Also, I don't think we should allow the longform URLs as it would decrease the readability of the file. That doesn't prevent people from using a wrong bug number. 656077 17 ojan 2012-06-23 07:10:18 -0700 (In reply to comment #16) > (In reply to comment #15) > > It helps people not make typos, e.g. the linter will catch if you type webkit.org/1234, which is a very common mistake. Also, I don't think we should allow the longform URLs as it would decrease the readability of the file. > > That doesn't prevent people from using a wrong bug number. I'm not sure what you're saying here. Yes, that's true, but I don't see how that relates. Just because we can't warn about every possible error doesn't mean we shouldn't warn the ones that we can. 656118 18 rniwa 2012-06-23 12:27:41 -0700 (In reply to comment #17) > I'm not sure what you're saying here. Yes, that's true, but I don't see how that relates. Just because we can't warn about every possible error doesn't mean we shouldn't warn the ones that we can. I'm saying that I don't see any value in verifying that bug URLs start with webkit.org/b/ or crbug.com/ because at the end of the day, people can introduce any typos there. And it'll be extremely annoying having to modify webkitpy code to support new URLs. That's unacceptable level of overhead. 656132 19 dpranke 2012-06-23 13:42:56 -0700 It is conceivable that people will write scripts and tools that will parse the files and want to do something with the URLs (I've done this before and will likely do it again, e.g. for the LTTF dashboard we used a couple years ago), and having some restrictions on what URLs might be used is useful in that case. Also, there's a pretty strong disincentive to adding more trackers, because people want webkit-related issues to be tracked on bugs.webkit.org. I personally get grumpy when I see things listed in rdar:// instead of b.w.o, and I can imagine others feel similarly about crbug (to that end, most of the crbugs have moved or should be moved to b.w.o, for example). That said, I don't feel strongly about this so those who do can decide what to do. 656215 20 ojan 2012-06-24 10:12:23 -0700 (In reply to comment #18) > (In reply to comment #17) > > I'm not sure what you're saying here. Yes, that's true, but I don't see how that relates. Just because we can't warn about every possible error doesn't mean we shouldn't warn the ones that we can. > > I'm saying that I don't see any value in verifying that bug URLs start with webkit.org/b/ or crbug.com/ because at the end of the day, people can introduce any typos there. And it'll be extremely annoying having to modify webkitpy code to support new URLs. That's unacceptable level of overhead. How often do people need to add support for new URL types? It's at most once per new port (i.e. less than once per year). Modifying a list in a python file is simply not a big overhead. I'm picturing code like the following: VALID_BUG_PREFIXES = ['crbug.com/', 'webkit.org/b/'] for prefix in VALID_BUG_PREFIXES: ... All you need to do is add an extra value to the list. It's arguably not even modifying code at that point. How is that a lot of overhead? People put new bug URLs in TestExpectations files many times every day. You can look at the history of threads on webkit-dev to see how often people accidentally leave out the "b/" in the webkit.org bug URLs. It's a very common mistake. One case of fallout to consider is that the flakiness dashboard will autolinkify these URLs. If they are mistyped, then the links won't work. As Dirk pointed out, any tooling we write for this data will rely on the URLs being valid. I've said my piece here though. I don't think there's more to discuss. If you still disagree, I won't block you committing this. I do strongly disagree though. I don't think this is making the right tradeoff. 656226 21 rniwa 2012-06-24 11:40:26 -0700 (In reply to comment #20) > How often do people need to add support for new URL types? It's at most once per new port (i.e. less than once per year). Modifying a list in a python file is simply not a big overhead. I'm picturing code like the following: > > VALID_BUG_PREFIXES = ['crbug.com/', 'webkit.org/b/'] > for prefix in VALID_BUG_PREFIXES: > ... > > All you need to do is add an extra value to the list. It's arguably not even modifying code at that point. How is that a lot of overhead? The fact it's buried in webkitpy code is the unacceptable part. Then we'll require adding a test, etc... I would be okay if it were in TestExpectations themselves as in: AllowedURLs: webkit.org/b/\d*, crbug.com/\d+ at the top of each file. Presumably, we can declare this at the top-level TestExpectations file once we support cascading. > People put new bug URLs in TestExpectations files many times every day. You can look at the history of threads on webkit-dev to see how often people accidentally leave out the "b/" in the webkit.org bug URLs. It's a very common mistake. We should just add webkit.org/12345 -> webkit.org/b/12345 alias then. 656230 22 rniwa 2012-06-24 12:02:17 -0700 (In reply to comment #21) > I would be okay if it were in TestExpectations themselves as in: > > AllowedURLs: webkit.org/b/\d*, crbug.com/\d+ On my second thought, this is such an over-engineered piece of cr*p. So I take it back. 670459 23 ojan 2012-07-16 10:49:34 -0700 Sorry if my comments stalled this moving forward. As I said, I'm fine with you moving on without us coming to agreement on the strictness of bug listings. FWIW, I just stumbled across the following typos in platform/chromium/TestExpectations: BUGKW76557 : svg/custom/transform-with-shadow-and-gradient.svg = IMAGE // This typo is repeated 8 times BUGW81803 MAC : platform/chromium/compositing/rubberbanding/transform-overhang-e.html = PASS IMAGE 670462 24 ojan 2012-07-16 10:56:30 -0700 I'm happy to review this patch if you expand it to include the the flakiness dashboard and garden-o-matic changes. I'm not actually sure you need to change anything in garden-o-matic. garden-o-matic just relies on webkit-patch for everything. It doesn't read the TestExpectations format at all AFAIK. 670544 25 abarth 2012-07-16 12:08:39 -0700 > I'm not actually sure you need to change anything in garden-o-matic. garden-o-matic just relies on webkit-patch for everything. It doesn't read the TestExpectations format at all AFAIK. Correct. 717761 26 dpranke 2012-09-11 17:34:19 -0700 I'm working on this now and will have a set of patches coming shortly. 717791 27 dpranke 2012-09-11 18:26:33 -0700 Note that while I'm using the refactoring that rniwa already landed, I'm not looking at the patch he posted to this at all, and instead taking a different approach. The general path I'm planning on for getting to the new syntax: 1) Refactor the code slightly to prepare for handling two syntaxes simultaneously 2) Implement reading in the new syntax by mapping it back onto the old syntax, so that the new parser is isolated and easily reviewable. Parsing will be done line by line, so a given file will support a mixture of both syntaxes. This significantly eases migration complexity, and hopefully won't show up much in practice. 3) Modify the serializer code to write out the new syntax rather than the old (to support webkit-patch rebaseline-expectations) 4) Concurrently w/ #3 - reformat and check in the existing files in the new format 5) Stop reading/supporting the old format 6) Clean up / refactor the code once support for the old format is no longer needed. My intent is for the time between 3) and 5) to be only about as long as it'll take me to land the patches and make sure nothing breaks, so that the period of time when both syntaxes are supported is short (hopefully only slightly longer than the window of a chromium roll, which will be needed to convert the downstream chromium expectations). I am not planning to support migrating patches that might contain the old syntax (though I have not yet figure out how to prevent such from landing and confusing things). I'm open to suggestions here one way or another. 717917 28 ojan 2012-09-11 22:13:58 -0700 (In reply to comment #27) > I am not planning to support migrating patches that might contain the old syntax (though I have not yet figure out how to prevent such from landing and confusing things). I'm open to suggestions here one way or another. Once the linter starts complaining for the old syntax, the presubmit will catch this and prevent a commit, no? 717940 29 dpranke 2012-09-11 23:07:12 -0700 (In reply to comment #28) > (In reply to comment #27) > > I am not planning to support migrating patches that might contain the old syntax (though I have not yet figure out how to prevent such from landing and confusing things). I'm open to suggestions here one way or another. > > Once the linter starts complaining for the old syntax, the presubmit will catch this and prevent a commit, no? Do the presubmit checks run on commit? I thought they only ran on upload. At any rate, I was more concerned about providing a tool to easily migrate old syntax to new that might be integrated into webkit-patch apply et al. It will be easy enough to add a separate tool (since I'll need one to migrate the files anyway) but I didn't want to have to integrate it into apply and (more importantly) I didn't want to set the expectation that people should expect it to work and as a result drag out the time when we were supporting both syntaxes. 147716 2012-06-14 20:14:30 -0700 2012-08-15 17:20:33 -0700 Patch bug-89161-20120614201856.patch text/plain 17096 rniwa SW5kZXg6IFRvb2xzL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBUb29scy9DaGFuZ2VMb2cJKHJl dmlzaW9uIDEyMDM5MykKKysrIFRvb2xzL0NoYW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwz ICsxLDQ5IEBACisyMDEyLTA2LTE0ICBSeW9zdWtlIE5pd2EgIDxybml3YUB3ZWJraXQub3JnPgor CisgICAgICAgIFN1cHBvcnQgbmV3IGZvcm1hdCBmb3IgdGVzdCBleHBlY3RhdGlvbnMKKyAgICAg ICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTg5MTYxCisKKyAgICAg ICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgTmV3IGZvcm1hdCBmb3Ig dGVzdCBleHBlY3RhdGlvbnMgcmUtb3JnYW5pemVzIG1vZGlmaWVycyBzbyB0aGF0IFdPTlRGSVgs IFNLSVAsIGFuZCBSRUJBU0VMSU5FIGFyZSB0cmVhdGVkCisgICAgICAgIGFzIHRlc3QgZXhwZWN0 YXRpb25zLCBtYWtpbmcgdGhlIHJlbWFpbmluZyBtb2RpZmllcnMgdG8gc2ltcGx5IHNwZWNpZnkg cGxhdGZvcm1zLgorCisgICAgICAgIEl0IHJlcGxhY2VzIEJVR1dLMTIzNDUsIEJVR0NSNjc4OTAs IGFuZCBCVUdSTklXQSBieSB3ZWJraXQub3JnLzEyMzQ1LCBjcmJ1Zy5jb20vNjc4OTAsIGFuZCBC dWcocm5pd2EpLAorICAgICAgICBhbmQgYWxsIHBsYXRmb3JtIGFuZCB0ZXN0IGV4cGVjdGF0aW9u IHRva2VucyB1c2VzIENhbWVsQ2FzZSBpbnN0ZWFkIG9mIEFMTCBDQVBJVEFMSVpFRCBMRVRURVJT LgorCisgICAgICAgIEluIGFkZGl0aW9uLCA6IGFuZCA9IGFyZSBhbHNvIHJlcGxhY2VkIGJ5IHBh aXJzIG9mIHNxdWFyZSBicmFja2V0cyB0byB3cmFwIHBsYXRmb3JtcyBhbmQgZXhwZWN0YXRpb25z IGFzIGluOgorICAgICAgICB3ZWJraXQub3JnLzEyMzQ1NiBbTWFjIERlYnVnXSBzb21lL3Rlc3Qu aHRtbCBbVGV4dF0KKworICAgICAgICBGaW5hbGx5LCBjb21tZW50cyBzdGFydCB3aXRoICMgaW5z dGVhZCBvZiAvLy4KKworICAgICAgICBUaGlzIGFkZHMgdGhlIHByZWxpbWluYXJ5IHN1cHBvcnQg Zm9yIHRoaXMgbmV3IHN5bnRheCBpbiB3ZWJraXRweS4KKworICAgICAgICAqIFNjcmlwdHMvd2Vi a2l0cHkvbGF5b3V0X3Rlc3RzL21vZGVscy90ZXN0X2V4cGVjdGF0aW9ucy5weToKKyAgICAgICAg KFRlc3RFeHBlY3RhdGlvblBhcnNlcik6CisgICAgICAgIChUZXN0RXhwZWN0YXRpb25QYXJzZXIu X3BhcnNlX21vZGlmaWVycyk6CisgICAgICAgIChUZXN0RXhwZWN0YXRpb25QYXJzZXIuX3Rva2Vu aXplKToKKyAgICAgICAgKFRlc3RFeHBlY3RhdGlvblBhcnNlci5fc3BsaXRfc3BhY2Vfc2VwYXJh dGVkKToKKyAgICAgICAgKiBTY3JpcHRzL3dlYmtpdHB5L2xheW91dF90ZXN0cy9tb2RlbHMvdGVz dF9leHBlY3RhdGlvbnNfdW5pdHRlc3QucHk6CisgICAgICAgIChCYXNpY1Rlc3RzLnRlc3RfbmV3 X2Zvcm1hdCk6CisgICAgICAgIChTZW1hbnRpY1Rlc3RzKToKKyAgICAgICAgKFRlc3RFeHBlY3Rh dGlvblBhcnNlclRlc3RzLnRlc3RfdG9rZW5pemVfZW1wdHlfYWx0ZXJuYXRpdmVfY29tbWVudCk6 CisgICAgICAgIChUZXN0RXhwZWN0YXRpb25QYXJzZXJUZXN0cyk6CisgICAgICAgIChUZXN0RXhw ZWN0YXRpb25QYXJzZXJUZXN0cy50ZXN0X3Rva2VuaXplX2FsdGVybmF0aXZlX2NvbW1lbnQpOgor ICAgICAgICAoVGVzdEV4cGVjdGF0aW9uUGFyc2VyVGVzdHMudGVzdF90b2tlbml6ZV92YWxpZF93 aXRoX2NvbW1lbnQpOgorICAgICAgICAoVGVzdEV4cGVjdGF0aW9uUGFyc2VyVGVzdHMudGVzdF90 b2tlbml6ZV92YWxpZF93aXRoX2FsdGVybmF0aXZlX2NvbW1lbnQpOgorICAgICAgICAoVGVzdEV4 cGVjdGF0aW9uUGFyc2VyVGVzdHMudGVzdF90b2tlbml6ZV9uZXdfdmFsaWRfZm9ybWF0KToKKyAg ICAgICAgKFRlc3RFeHBlY3RhdGlvblBhcnNlclRlc3RzLnRlc3RfdG9rZW5pemVfbmV3X2Zvcm1h dF93aXRoX3dlYmtpdF9idWcpOgorICAgICAgICAoVGVzdEV4cGVjdGF0aW9uUGFyc2VyVGVzdHMu dGVzdF90b2tlbml6ZV9uZXdfZm9ybWF0X3dpdGhvdXRfZGVzY3JpcHRpb24pOgorICAgICAgICAo VGVzdEV4cGVjdGF0aW9uUGFyc2VyVGVzdHMudGVzdF90b2tlbml6ZV9uZXdfZm9ybWF0X3dpdGhv dXRfZXhwZWN0YXRpb25zKToKKyAgICAgICAgKFRlc3RFeHBlY3RhdGlvblBhcnNlclRlc3RzLnRl c3RfdG9rZW5pemVfbmV3X2Zvcm1hdF93aXRoX3BsYXRmb3JtKToKKyAgICAgICAgKFRlc3RFeHBl Y3RhdGlvblBhcnNlclRlc3RzLnRlc3RfdG9rZW5pemVfbmV3X2Zvcm1hdF93aXRoX3dvbnRmaXhf YnVnKToKKyAgICAgICAgKFRlc3RFeHBlY3RhdGlvblBhcnNlclRlc3RzLnRlc3RfdG9rZW5pemVf bmV3X2Zvcm1hdF93aXRoX3dvbnRmaXgpOgorICAgICAgICAoVGVzdEV4cGVjdGF0aW9uUGFyc2Vy VGVzdHMudGVzdF90b2tlbml6ZV9uZXdfZm9ybWF0X3dpdGhfZXh0cmFfYW5nbGVfYnJhY2tldCk6 CisgICAgICAgIChUZXN0RXhwZWN0YXRpb25QYXJzZXJUZXN0cy50ZXN0X3Rva2VuaXplX25ld19m b3JtYXRfd2l0aF9za2lwKToKKyAgICAgICAgKFRlc3RFeHBlY3RhdGlvblBhcnNlclRlc3RzLnRl c3RfdG9rZW5pemVfbmV3X2Zvcm1hdF93aXRoX3dvbnRmaXhfYW5kX290aGVyX2V4cGVjdGF0aW9u KToKKyAgICAgICAgKiBTY3JpcHRzL3dlYmtpdHB5L2xheW91dF90ZXN0cy9ydW5fd2Via2l0X3Rl c3RzX2ludGVncmF0aW9udGVzdC5weToKKyAgICAgICAgKExpbnRUZXN0LnRlc3RfbGludF90ZXN0 X2ZpbGVzX19lcnJvcnMpOgorCiAyMDEyLTA2LTE0ICBEb25nd29vIEltICA8ZHcuaW1Ac2Ftc3Vu Zy5jb20+CiAKICAgICAgICAgW0VGTF0gW0RSVF0gUmVzZXQgdGhlIFdlYkF1ZGlvIHNldHRpbmcg b24gRHVtcFJlbmRlclRyZWUKSW5kZXg6IFRvb2xzL1NjcmlwdHMvd2Via2l0cHkvbGF5b3V0X3Rl c3RzL3J1bl93ZWJraXRfdGVzdHNfaW50ZWdyYXRpb250ZXN0LnB5Cj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFRv b2xzL1NjcmlwdHMvd2Via2l0cHkvbGF5b3V0X3Rlc3RzL3J1bl93ZWJraXRfdGVzdHNfaW50ZWdy YXRpb250ZXN0LnB5CShyZXZpc2lvbiAxMjAzNzEpCisrKyBUb29scy9TY3JpcHRzL3dlYmtpdHB5 L2xheW91dF90ZXN0cy9ydW5fd2Via2l0X3Rlc3RzX2ludGVncmF0aW9udGVzdC5weQkod29ya2lu ZyBjb3B5KQpAQCAtMjU4LDcgKzI1OCw3IEBAIGNsYXNzIExpbnRUZXN0KHVuaXR0ZXN0LlRlc3RD YXNlLCBTdHJlYW0KICAgICAgICAgb3B0aW9ucywgcGFyc2VkX2FyZ3MgPSBwYXJzZV9hcmdzKFsn LS1saW50LXRlc3QtZmlsZXMnXSkKICAgICAgICAgaG9zdCA9IE1vY2tIb3N0KCkKICAgICAgICAg cG9ydF9vYmogPSBob3N0LnBvcnRfZmFjdG9yeS5nZXQob3B0aW9ucy5wbGF0Zm9ybSwgb3B0aW9u cz1vcHRpb25zKQotICAgICAgICBwb3J0X29iai5leHBlY3RhdGlvbnNfZGljdCA9IGxhbWJkYTog eycnOiAnIyBzeW50YXggZXJyb3InfQorICAgICAgICBwb3J0X29iai5leHBlY3RhdGlvbnNfZGlj dCA9IGxhbWJkYTogeycnOiAnYSAjIHN5bnRheCBlcnJvcid9CiAgICAgICAgIHJlcywgb3V0LCBl cnIgPSBydW5fYW5kX2NhcHR1cmUocG9ydF9vYmosIG9wdGlvbnMsIHBhcnNlZF9hcmdzKQogCiAg ICAgICAgIHNlbGYuYXNzZXJ0RXF1YWwocmVzLCAtMSkKSW5kZXg6IFRvb2xzL1NjcmlwdHMvd2Vi a2l0cHkvbGF5b3V0X3Rlc3RzL21vZGVscy90ZXN0X2V4cGVjdGF0aW9ucy5weQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 Ci0tLSBUb29scy9TY3JpcHRzL3dlYmtpdHB5L2xheW91dF90ZXN0cy9tb2RlbHMvdGVzdF9leHBl Y3RhdGlvbnMucHkJKHJldmlzaW9uIDEyMDM3MSkKKysrIFRvb2xzL1NjcmlwdHMvd2Via2l0cHkv bGF5b3V0X3Rlc3RzL21vZGVscy90ZXN0X2V4cGVjdGF0aW9ucy5weQkod29ya2luZyBjb3B5KQpA QCAtMjA3LDggKzIwNyw2IEBAIGNsYXNzIFRlc3RFeHBlY3RhdGlvblBhcnNlcihvYmplY3QpOgog ICAgICIiIlByb3ZpZGVzIHBhcnNpbmcgZmFjaWxpdGllcyBmb3IgbGluZXMgaW4gdGhlIHRlc3Rf ZXhwZWN0YXRpb24udHh0IGZpbGUuIiIiCiAKICAgICBEVU1NWV9CVUdfTU9ESUZJRVIgPSAiYnVn X2R1bW15IgotICAgIEJVR19NT0RJRklFUl9QUkVGSVggPSAnYnVnJwotICAgIEJVR19NT0RJRklF Ul9SRUdFWCA9ICdidWdcZCsnCiAgICAgUkVCQVNFTElORV9NT0RJRklFUiA9ICdyZWJhc2VsaW5l JwogICAgIFBBU1NfRVhQRUNUQVRJT04gPSAncGFzcycKICAgICBTS0lQX01PRElGSUVSID0gJ3Nr aXAnCkBAIC0yNzAsMTIgKzI2OCw5IEBAIGNsYXNzIFRlc3RFeHBlY3RhdGlvblBhcnNlcihvYmpl Y3QpOgogICAgICAgICAgICAgICAgIGV4cGVjdGF0aW9uX2xpbmUucGFyc2VkX21vZGlmaWVycy5h cHBlbmQobW9kaWZpZXIpCiAgICAgICAgICAgICAgICAgaWYgbW9kaWZpZXIgPT0gc2VsZi5XT05U RklYX01PRElGSUVSOgogICAgICAgICAgICAgICAgICAgICBoYXNfd29udGZpeCA9IFRydWUKLSAg ICAgICAgICAgIGVsaWYgbW9kaWZpZXIuc3RhcnRzd2l0aChzZWxmLkJVR19NT0RJRklFUl9QUkVG SVgpOgorICAgICAgICAgICAgZWxpZiBtb2RpZmllci5sb3dlcigpLnN0YXJ0c3dpdGgoJ2J1Zycp IG9yICcvJyBpbiBtb2RpZmllcjoKICAgICAgICAgICAgICAgICBoYXNfYnVnaWQgPSBUcnVlCi0g ICAgICAgICAgICAgICAgaWYgcmUubWF0Y2goc2VsZi5CVUdfTU9ESUZJRVJfUkVHRVgsIG1vZGlm aWVyKToKLSAgICAgICAgICAgICAgICAgICAgZXhwZWN0YXRpb25fbGluZS53YXJuaW5ncy5hcHBl bmQoJ0JVR1xkKyBpcyBub3QgYWxsb3dlZCwgbXVzdCBiZSBvbmUgb2YgQlVHQ1JcZCssIEJVR1dL XGQrLCBCVUdWOF9cZCssIG9yIGEgbm9uLW51bWVyaWMgYnVnIGlkZW50aWZpZXIuJykKLSAgICAg ICAgICAgICAgICBlbHNlOgotICAgICAgICAgICAgICAgICAgICBleHBlY3RhdGlvbl9saW5lLnBh cnNlZF9idWdfbW9kaWZpZXJzLmFwcGVuZChtb2RpZmllcikKKyAgICAgICAgICAgICAgICBleHBl Y3RhdGlvbl9saW5lLnBhcnNlZF9idWdfbW9kaWZpZXJzLmFwcGVuZChtb2RpZmllcikKICAgICAg ICAgICAgIGVsc2U6CiAgICAgICAgICAgICAgICAgcGFyc2VkX3NwZWNpZmllcnMuYWRkKG1vZGlm aWVyKQogCkBAIC0zMzcsNiArMzMyLDExIEBAIGNsYXNzIFRlc3RFeHBlY3RhdGlvblBhcnNlcihv YmplY3QpOgogICAgICAgICBpZiBleHBlY3RhdGlvbl9saW5lLnBhdGggaW4gc2VsZi5fZnVsbF90 ZXN0X2xpc3Q6CiAgICAgICAgICAgICBleHBlY3RhdGlvbl9saW5lLm1hdGNoaW5nX3Rlc3RzLmFw cGVuZChleHBlY3RhdGlvbl9saW5lLnBhdGgpCiAKKyAgICB0ZXN0X2V4cGVjdGF0aW9uX3JlZ2V4 ID0gcmUuY29tcGlsZShyIiIiXigoP1A8ZGVzY3JpcHRpb24+W15cW10qKVxzKyk/CisgICAgICAg IChcWyg/UDxwbGF0Zm9ybXM+W0EtWmEtelxzXSspXF1ccyspPworICAgICAgICAoP1A8dGVzdD5b XlxbXHNdKykKKyAgICAgICAgKFxzK1xbKD9QPGV4cGVjdGF0aW9ucz5bQS1aYS16XHNdKylcXSk/ JCIiIiwgcmUuVkVSQk9TRSkKKwogICAgIEBjbGFzc21ldGhvZAogICAgIGRlZiBfdG9rZW5pemUo Y2xzLCBmaWxlbmFtZSwgZXhwZWN0YXRpb25fc3RyaW5nLCBsaW5lX251bWJlcik6CiAgICAgICAg ICIiIlRva2VuaXplcyBhIGxpbmUgZnJvbSBUZXN0RXhwZWN0YXRpb25zIGFuZCByZXR1cm5zIGFu IHVucGFyc2VkIFRlc3RFeHBlY3RhdGlvbkxpbmUgaW5zdGFuY2UuCkBAIC0zNTMsMTUgKzM1Myw1 NSBAQCBjbGFzcyBUZXN0RXhwZWN0YXRpb25QYXJzZXIob2JqZWN0KToKICAgICAgICAgZXhwZWN0 YXRpb25fbGluZS5saW5lX251bWJlciA9IGxpbmVfbnVtYmVyCiAgICAgICAgIGV4cGVjdGF0aW9u X2xpbmUuZmlsZW5hbWUgPSBmaWxlbmFtZQogICAgICAgICBjb21tZW50X2luZGV4ID0gZXhwZWN0 YXRpb25fc3RyaW5nLmZpbmQoIi8vIikKLSAgICAgICAgaWYgY29tbWVudF9pbmRleCA9PSAtMToK KworICAgICAgICBhbHRlcm5hdGl2ZV9jb21tZW50X2luZGV4ID0gZXhwZWN0YXRpb25fc3RyaW5n LmZpbmQoIiMiKQorICAgICAgICBpZiBhbHRlcm5hdGl2ZV9jb21tZW50X2luZGV4ID49IDAgYW5k IChhbHRlcm5hdGl2ZV9jb21tZW50X2luZGV4IDwgY29tbWVudF9pbmRleCBvciBjb21tZW50X2lu ZGV4IDwgMCk6CisgICAgICAgICAgICBjb21tZW50X2luZGV4ID0gYWx0ZXJuYXRpdmVfY29tbWVu dF9pbmRleAorCisgICAgICAgIGlmIGNvbW1lbnRfaW5kZXggPCAwOgogICAgICAgICAgICAgY29t bWVudF9pbmRleCA9IGxlbihleHBlY3RhdGlvbl9zdHJpbmcpCiAgICAgICAgIGVsc2U6Ci0gICAg ICAgICAgICBleHBlY3RhdGlvbl9saW5lLmNvbW1lbnQgPSBleHBlY3RhdGlvbl9zdHJpbmdbY29t bWVudF9pbmRleCArIDI6XQorICAgICAgICAgICAgZXhwZWN0YXRpb25fbGluZS5jb21tZW50ID0g ZXhwZWN0YXRpb25fc3RyaW5nW2NvbW1lbnRfaW5kZXggKyAoMSBpZiBleHBlY3RhdGlvbl9zdHJp bmdbY29tbWVudF9pbmRleF0gPT0gJyMnIGVsc2UgMik6XQogCiAgICAgICAgIHJlbWFpbmluZ19z dHJpbmcgPSByZS5zdWIociJccysiLCAiICIsIGV4cGVjdGF0aW9uX3N0cmluZ1s6Y29tbWVudF9p bmRleF0uc3RyaXAoKSkKICAgICAgICAgaWYgbGVuKHJlbWFpbmluZ19zdHJpbmcpID09IDA6CiAg ICAgICAgICAgICByZXR1cm4gZXhwZWN0YXRpb25fbGluZQogCisgICAgICAgIGhhc19zcXVhcmVf YnJhY2tldCA9IHJlbWFpbmluZ19zdHJpbmcuZmluZCgnWycpID49IDAKKyAgICAgICAgIyBBc3N1 bWUgbmV3IHN5bnRheCBpZiB3ZSBzZWUgWywgd2Via2l0Lm9yZywgb3IgY3JidWcuY29tLgorICAg ICAgICBpZiBoYXNfc3F1YXJlX2JyYWNrZXQgb3IgcmVtYWluaW5nX3N0cmluZy5maW5kKCd3ZWJr aXQub3JnJykgPj0gMCBvciByZW1haW5pbmdfc3RyaW5nLmZpbmQoJ2NyYnVnLmNvbScpID49IDA6 CisgICAgICAgICAgICBtYXRjaCA9IGNscy50ZXN0X2V4cGVjdGF0aW9uX3JlZ2V4Lm1hdGNoKHJl bWFpbmluZ19zdHJpbmcpCisgICAgICAgICAgICBpZiBub3QgbWF0Y2ggYW5kIGhhc19zcXVhcmVf YnJhY2tldDoKKyAgICAgICAgICAgICAgICBleHBlY3RhdGlvbl9saW5lLndhcm5pbmdzLmFwcGVu ZCgiRmFpbGVkIHRvIHBhcnNlIikKKyAgICAgICAgICAgICAgICByZXR1cm4gZXhwZWN0YXRpb25f bGluZQorICAgICAgICAgICAgZWxpZiBtYXRjaDoKKyAgICAgICAgICAgICAgICBncm91cHMgPSBt YXRjaC5ncm91cGRpY3QoKQorICAgICAgICAgICAgICAgIGV4cGVjdGF0aW9uX2xpbmUubW9kaWZp ZXJzID0gY2xzLl9zcGxpdF9zcGFjZV9zZXBhcmF0ZWQoZ3JvdXBzLmdldCgncGxhdGZvcm1zJywg Tm9uZSkpCisgICAgICAgICAgICAgICAgaWYgZ3JvdXBzLmdldCgnZGVzY3JpcHRpb24nLCBOb25l KToKKyAgICAgICAgICAgICAgICAgICAgZXhwZWN0YXRpb25fbGluZS5tb2RpZmllcnMuaW5zZXJ0 KDAsIGdyb3Vwc1snZGVzY3JpcHRpb24nXSkKKyAgICAgICAgICAgICAgICBleHBlY3RhdGlvbl9s aW5lLm5hbWUgPSBncm91cHMuZ2V0KCd0ZXN0JywgTm9uZSkKKyAgICAgICAgICAgICAgICBleHBl Y3RhdGlvbl9saW5lLmV4cGVjdGF0aW9ucyA9IGNscy5fc3BsaXRfc3BhY2Vfc2VwYXJhdGVkKGdy b3Vwcy5nZXQoJ2V4cGVjdGF0aW9ucycsIE5vbmUpKQorCisgICAgICAgICAgICAgICAgIyBGSVhN RTogQ2xlYW4gdXAgdGhpcyBtZXNzIG9uY2Ugd2UgdHJhbnNpdGlvbmVkIHRvIG5ldyBmb3JtYXQK KyAgICAgICAgICAgICAgICBpZiAnc2tpcCcgaW4gZXhwZWN0YXRpb25fbGluZS5leHBlY3RhdGlv bnM6CisgICAgICAgICAgICAgICAgICAgIGV4cGVjdGF0aW9uX2xpbmUud2FybmluZ3MuYXBwZW5k KCJTa2lwIG1vZGlmaWVyIGhhcyBiZWVuIGRlcHJlY2F0ZWQiKQorCisgICAgICAgICAgICAgICAg IyBGSVhNRTogU2hvdWxkIHdlIHN1cHBvcnQgcmViYXNlbGluZSBtb2RpZmllciBhdCBhbGw/Cisg ICAgICAgICAgICAgICAgaWYgJ3JlYmFzZWxpbmUnIGluIGV4cGVjdGF0aW9uX2xpbmUuZXhwZWN0 YXRpb25zOgorICAgICAgICAgICAgICAgICAgICBleHBlY3RhdGlvbl9saW5lLmV4cGVjdGF0aW9u cy5yZW1vdmUoJ3JlYmFzZWxpbmUnKQorICAgICAgICAgICAgICAgICAgICBleHBlY3RhdGlvbl9s aW5lLm1vZGlmaWVycy5pbnNlcnQoMCwgJ3JlYmFzZWxpbmUnKQorCisgICAgICAgICAgICAgICAg aWYgJ3dvbnRmaXgnIGluIGV4cGVjdGF0aW9uX2xpbmUuZXhwZWN0YXRpb25zOgorICAgICAgICAg ICAgICAgICAgICBleHBlY3RhdGlvbl9saW5lLmV4cGVjdGF0aW9ucy5yZW1vdmUoJ3dvbnRmaXgn KQorICAgICAgICAgICAgICAgICAgICBpZiBsZW4oZXhwZWN0YXRpb25fbGluZS5leHBlY3RhdGlv bnMpOgorICAgICAgICAgICAgICAgICAgICAgICAgZXhwZWN0YXRpb25fbGluZS53YXJuaW5ncy5h cHBlbmQoIldvbnRGaXggc2hvdWxkIG5vdCBiZSB1c2VkIHdpdGggYW55IG90aGVyIGV4cGVjdGF0 aW9uIikKKyAgICAgICAgICAgICAgICAgICAgZXhwZWN0YXRpb25fbGluZS5tb2RpZmllcnMuYXBw ZW5kKCd3b250Zml4JykKKworICAgICAgICAgICAgICAgIGlmIG5vdCBsZW4oZXhwZWN0YXRpb25f bGluZS5leHBlY3RhdGlvbnMpOgorICAgICAgICAgICAgICAgICAgICBleHBlY3RhdGlvbl9saW5l Lm1vZGlmaWVycy5hcHBlbmQoJ3NraXAnKQorCisgICAgICAgICAgICAgICAgcmV0dXJuIGV4cGVj dGF0aW9uX2xpbmUKKwogICAgICAgICBwYXJ0cyA9IHJlbWFpbmluZ19zdHJpbmcuc3BsaXQoJzon KQogICAgICAgICBpZiBsZW4ocGFydHMpICE9IDI6CiAgICAgICAgICAgICBleHBlY3RhdGlvbl9s aW5lLndhcm5pbmdzLmFwcGVuZCgiTWlzc2luZyBhICc6JyIgaWYgbGVuKHBhcnRzKSA8IDIgZWxz ZSAiRXh0cmFuZW91cyAnOiciKQpAQCAtMzkxLDYgKzQzMSw4IEBAIGNsYXNzIFRlc3RFeHBlY3Rh dGlvblBhcnNlcihvYmplY3QpOgogICAgIGRlZiBfc3BsaXRfc3BhY2Vfc2VwYXJhdGVkKGNscywg c3BhY2Vfc2VwYXJhdGVkX3N0cmluZyk6CiAgICAgICAgICIiIlNwbGl0cyBhIHNwYWNlLXNlcGFy YXRlZCBzdHJpbmcgaW50byBhbiBhcnJheS4iIiIKICAgICAgICAgIyBGSVhNRTogTG93ZXItY2Fz aW5nIGlzIG5lY2Vzc2FyeSB0byBzdXBwb3J0IGxlZ2FjeSBjb2RlLiBOZWVkIHRvIGVsaW1pbmF0 ZS4KKyAgICAgICAgaWYgbm90IHNwYWNlX3NlcGFyYXRlZF9zdHJpbmc6CisgICAgICAgICAgICBy ZXR1cm4gW10KICAgICAgICAgcmV0dXJuIFtwYXJ0LnN0cmlwKCkubG93ZXIoKSBmb3IgcGFydCBp biBzcGFjZV9zZXBhcmF0ZWRfc3RyaW5nLnN0cmlwKCkuc3BsaXQoJyAnKV0KIAogCkluZGV4OiBU b29scy9TY3JpcHRzL3dlYmtpdHB5L2xheW91dF90ZXN0cy9tb2RlbHMvdGVzdF9leHBlY3RhdGlv bnNfdW5pdHRlc3QucHkKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gVG9vbHMvU2NyaXB0cy93ZWJraXRweS9sYXlv dXRfdGVzdHMvbW9kZWxzL3Rlc3RfZXhwZWN0YXRpb25zX3VuaXR0ZXN0LnB5CShyZXZpc2lvbiAx MjAzNzEpCisrKyBUb29scy9TY3JpcHRzL3dlYmtpdHB5L2xheW91dF90ZXN0cy9tb2RlbHMvdGVz dF9leHBlY3RhdGlvbnNfdW5pdHRlc3QucHkJKHdvcmtpbmcgY29weSkKQEAgLTE0Niw2ICsxNDYs MTkgQEAgY2xhc3MgQmFzaWNUZXN0cyhCYXNlKToKICAgICAgICAgc2VsZi5hc3NlcnRfZXhwKCdw YXNzZXMvdGV4dC5odG1sJywgUEFTUykKICAgICAgICAgc2VsZi5hc3NlcnRfZXhwKCdmYWlsdXJl cy9leHBlY3RlZC9pbWFnZS5odG1sJywgUEFTUykKIAorICAgIGRlZiB0ZXN0X25ld19mb3JtYXQo c2VsZik6CisgICAgICAgIHNlbGYucGFyc2VfZXhwKCIiIgorQnVnKHJuaXdhKSBmYWlsdXJlcy9l eHBlY3RlZC90ZXh0Lmh0bWwgW1RleHRdCitCdWcocm5pd2EpIGZhaWx1cmVzL2V4cGVjdGVkL2Ny YXNoLmh0bWwgW1dvbnRGaXhdCitCdWcocm5pd2EpIGZhaWx1cmVzL2V4cGVjdGVkL21pc3Npbmdf aW1hZ2UuaHRtbCBbUmViYXNlbGluZV0KK3dlYmtpdC5vcmcvYi8xMjM0NSBmYWlsdXJlcy9leHBl Y3RlZC9pbWFnZV9jaGVja3N1bS5odG1sIFtJbWFnZV0KK3dlYmtpdC5vcmcvYi81Njc4OSBbTWFj XSBmYWlsdXJlcy9leHBlY3RlZC9pbWFnZS5odG1sID0gW1dvbnRGaXhdCisiIiIpCisgICAgICAg IHNlbGYuYXNzZXJ0X2V4cCgnZmFpbHVyZXMvZXhwZWN0ZWQvdGV4dC5odG1sJywgVEVYVCkKKyAg ICAgICAgc2VsZi5hc3NlcnRfZXhwKCdmYWlsdXJlcy9leHBlY3RlZC9pbWFnZV9jaGVja3N1bS5o dG1sJywgSU1BR0UpCisgICAgICAgIHNlbGYuYXNzZXJ0X2V4cCgncGFzc2VzL3RleHQuaHRtbCcs IFBBU1MpCisgICAgICAgIHNlbGYuYXNzZXJ0X2V4cCgnZmFpbHVyZXMvZXhwZWN0ZWQvaW1hZ2Uu aHRtbCcsIFBBU1MpCisKIAogY2xhc3MgTWlzY1Rlc3RzKEJhc2UpOgogICAgIGRlZiB0ZXN0X211 bHRpcGxlX3Jlc3VsdHMoc2VsZik6CkBAIC0zMzcsMTYgKzM1MCw2IEBAIEJVR19URVNUIFdJTiA6 IGZhaWx1cmVzL2V4cGVjdGVkL3RleHQuaHQKIAogCiBjbGFzcyBTZW1hbnRpY1Rlc3RzKEJhc2Up OgotICAgIGRlZiB0ZXN0X2J1Z19mb3JtYXQoc2VsZik6Ci0gICAgICAgIHNlbGYuYXNzZXJ0UmFp c2VzKFBhcnNlRXJyb3IsIHNlbGYucGFyc2VfZXhwLCAnQlVHMTIzNCA6IGZhaWx1cmVzL2V4cGVj dGVkL3RleHQuaHRtbCA9IFRFWFQnLCBpc19saW50X21vZGU9VHJ1ZSkKLQotICAgIGRlZiB0ZXN0 X2JhZF9idWdpZChzZWxmKToKLSAgICAgICAgdHJ5OgotICAgICAgICAgICAgc2VsZi5wYXJzZV9l eHAoJ0JVRzEyMzQgU0xPVyA6IGZhaWx1cmVzL2V4cGVjdGVkL3RleHQuaHRtbCA9IFRFWFQnLCBp c19saW50X21vZGU9VHJ1ZSkKLSAgICAgICAgICAgIHNlbGYuZmFpbCgnc2hvdWxkIGhhdmUgcmFp c2VkIGFuIGVycm9yIGFib3V0IGEgYmFkIGJ1ZyBpZGVudGlmaWVyJykKLSAgICAgICAgZXhjZXB0 IFBhcnNlRXJyb3IsIGV4cDoKLSAgICAgICAgICAgIHNlbGYuYXNzZXJ0RXF1YWxzKGxlbihleHAu d2FybmluZ3MpLCAxKQotCiAgICAgZGVmIHRlc3RfbWlzc2luZ19idWdpZChzZWxmKToKICAgICAg ICAgc2VsZi5wYXJzZV9leHAoJ1NMT1cgOiBmYWlsdXJlcy9leHBlY3RlZC90ZXh0Lmh0bWwgPSBU RVhUJykKICAgICAgICAgc2VsZi5hc3NlcnRUcnVlKHNlbGYuX2V4cC5oYXNfd2FybmluZ3MoKSkK QEAgLTUwMSw2ICs1MDQsMTYgQEAgY2xhc3MgVGVzdEV4cGVjdGF0aW9uUGFyc2VyVGVzdHModW5p dHRlcwogICAgICAgICBzZWxmLmFzc2VydEVxdWFsKGV4cGVjdGF0aW9uLmNvbW1lbnQsICdRdXgu JykKICAgICAgICAgc2VsZi5hc3NlcnRFcXVhbChsZW4oZXhwZWN0YXRpb24ud2FybmluZ3MpLCAw KQogCisgICAgZGVmIHRlc3RfdG9rZW5pemVfZW1wdHlfYWx0ZXJuYXRpdmVfY29tbWVudChzZWxm KToKKyAgICAgICAgZXhwZWN0YXRpb24gPSBzZWxmLl90b2tlbml6ZSgnIycpCisgICAgICAgIHNl bGYuYXNzZXJ0RXF1YWwoZXhwZWN0YXRpb24uY29tbWVudCwgJycpCisgICAgICAgIHNlbGYuYXNz ZXJ0RXF1YWwobGVuKGV4cGVjdGF0aW9uLndhcm5pbmdzKSwgMCkKKworICAgIGRlZiB0ZXN0X3Rv a2VuaXplX2FsdGVybmF0aXZlX2NvbW1lbnQoc2VsZik6CisgICAgICAgIGV4cGVjdGF0aW9uID0g c2VsZi5fdG9rZW5pemUoJyNRdXguJykKKyAgICAgICAgc2VsZi5hc3NlcnRFcXVhbChleHBlY3Rh dGlvbi5jb21tZW50LCAnUXV4LicpCisgICAgICAgIHNlbGYuYXNzZXJ0RXF1YWwobGVuKGV4cGVj dGF0aW9uLndhcm5pbmdzKSwgMCkKKwogICAgIGRlZiB0ZXN0X3Rva2VuaXplX21pc3NpbmdfZXF1 YWwoc2VsZik6CiAgICAgICAgIGV4cGVjdGF0aW9uID0gc2VsZi5fdG9rZW5pemUoJ0ZPTyA6IGJh cicpCiAgICAgICAgIHNlbGYuYXNzZXJ0RXF1YWwoc3RyKGV4cGVjdGF0aW9uLndhcm5pbmdzKSwg IlsnTWlzc2luZyBleHBlY3RhdGlvbnNcJ10iKQpAQCAtNTE1LDggKzUyOCwxNSBAQCBjbGFzcyBU ZXN0RXhwZWN0YXRpb25QYXJzZXJUZXN0cyh1bml0dGVzCiAgICAgICAgIHNlbGYuYXNzZXJ0RXF1 YWwobGVuKGV4cGVjdGF0aW9uLndhcm5pbmdzKSwgMCkKIAogICAgIGRlZiB0ZXN0X3Rva2VuaXpl X3ZhbGlkX3dpdGhfY29tbWVudChzZWxmKToKLSAgICAgICAgZXhwZWN0YXRpb24gPSBzZWxmLl90 b2tlbml6ZSgnRk9PIDogYmFyID0gQkFaIC8vUXV4LicpCi0gICAgICAgIHNlbGYuYXNzZXJ0RXF1 YWwoZXhwZWN0YXRpb24uY29tbWVudCwgJ1F1eC4nKQorICAgICAgICBleHBlY3RhdGlvbiA9IHNl bGYuX3Rva2VuaXplKCdGT08gOiBiYXIgPSBCQVogLy9RdXggIy4nKQorICAgICAgICBzZWxmLmFz c2VydEVxdWFsKGV4cGVjdGF0aW9uLmNvbW1lbnQsICdRdXggIy4nKQorICAgICAgICBzZWxmLmFz c2VydEVxdWFsKHN0cihleHBlY3RhdGlvbi5tb2RpZmllcnMpLCAnW1wnZm9vXCddJykKKyAgICAg ICAgc2VsZi5hc3NlcnRFcXVhbChzdHIoZXhwZWN0YXRpb24uZXhwZWN0YXRpb25zKSwgJ1tcJ2Jh elwnXScpCisgICAgICAgIHNlbGYuYXNzZXJ0RXF1YWwobGVuKGV4cGVjdGF0aW9uLndhcm5pbmdz KSwgMCkKKworICAgIGRlZiB0ZXN0X3Rva2VuaXplX3ZhbGlkX3dpdGhfYWx0ZXJuYXRpdmVfY29t bWVudChzZWxmKToKKyAgICAgICAgZXhwZWN0YXRpb24gPSBzZWxmLl90b2tlbml6ZSgnRk9PIDog YmFyID0gQkFaICNRdXggLy8uJykKKyAgICAgICAgc2VsZi5hc3NlcnRFcXVhbChleHBlY3RhdGlv bi5jb21tZW50LCAnUXV4IC8vLicpCiAgICAgICAgIHNlbGYuYXNzZXJ0RXF1YWwoc3RyKGV4cGVj dGF0aW9uLm1vZGlmaWVycyksICdbXCdmb29cJ10nKQogICAgICAgICBzZWxmLmFzc2VydEVxdWFs KHN0cihleHBlY3RhdGlvbi5leHBlY3RhdGlvbnMpLCAnW1wnYmF6XCddJykKICAgICAgICAgc2Vs Zi5hc3NlcnRFcXVhbChsZW4oZXhwZWN0YXRpb24ud2FybmluZ3MpLCAwKQpAQCAtNTM5LDYgKzU1 OSw3NCBAQCBjbGFzcyBUZXN0RXhwZWN0YXRpb25QYXJzZXJUZXN0cyh1bml0dGVzCiAgICAgICAg IHBhcnNlci5fcGFyc2VfbGluZShleHBlY3RhdGlvbl9saW5lKQogICAgICAgICBzZWxmLmFzc2Vy dEZhbHNlKGV4cGVjdGF0aW9uX2xpbmUuaXNfaW52YWxpZCgpKQogCisgICAgZGVmIHRlc3RfdG9r ZW5pemVfbmV3X3ZhbGlkX2Zvcm1hdChzZWxmKToKKyAgICAgICAgZXhwZWN0YXRpb24gPSBzZWxm Ll90b2tlbml6ZSgnYnVnKHJuaXdhKSBzb21lL3Rlc3QuaHRtbCBbQkFaXScpCisgICAgICAgIHNl bGYuYXNzZXJ0RXF1YWwoZXhwZWN0YXRpb24ubmFtZSwgJ3NvbWUvdGVzdC5odG1sJykKKyAgICAg ICAgc2VsZi5hc3NlcnRFcXVhbChleHBlY3RhdGlvbi5tb2RpZmllcnMsIFsnYnVnKHJuaXdhKSdd KQorICAgICAgICBzZWxmLmFzc2VydEVxdWFsKGV4cGVjdGF0aW9uLmV4cGVjdGF0aW9ucywgWydi YXonXSkKKyAgICAgICAgc2VsZi5hc3NlcnRFcXVhbChleHBlY3RhdGlvbi5jb21tZW50LCBOb25l KQorICAgICAgICBzZWxmLmFzc2VydEVxdWFsKGxlbihleHBlY3RhdGlvbi53YXJuaW5ncyksIDAp CisKKyAgICBkZWYgdGVzdF90b2tlbml6ZV9uZXdfZm9ybWF0X3dpdGhfd2Via2l0X2J1ZyhzZWxm KToKKyAgICAgICAgZXhwZWN0YXRpb24gPSBzZWxmLl90b2tlbml6ZSgnd2Via2l0Lm9yZy9iLzEy MzQ1IHNvbWUvdGVzdC5odG1sIFtCQVpdJykKKyAgICAgICAgc2VsZi5hc3NlcnRFcXVhbChleHBl Y3RhdGlvbi5uYW1lLCAnc29tZS90ZXN0Lmh0bWwnKQorICAgICAgICBzZWxmLmFzc2VydEVxdWFs KGV4cGVjdGF0aW9uLm1vZGlmaWVycywgWyd3ZWJraXQub3JnL2IvMTIzNDUnXSkKKyAgICAgICAg c2VsZi5hc3NlcnRFcXVhbChleHBlY3RhdGlvbi5leHBlY3RhdGlvbnMsIFsnYmF6J10pCisgICAg ICAgIHNlbGYuYXNzZXJ0RXF1YWwoZXhwZWN0YXRpb24uY29tbWVudCwgTm9uZSkKKyAgICAgICAg c2VsZi5hc3NlcnRFcXVhbChsZW4oZXhwZWN0YXRpb24ud2FybmluZ3MpLCAwKQorCisgICAgZGVm IHRlc3RfdG9rZW5pemVfbmV3X2Zvcm1hdF93aXRob3V0X2Rlc2NyaXB0aW9uKHNlbGYpOgorICAg ICAgICBleHBlY3RhdGlvbiA9IHNlbGYuX3Rva2VuaXplKCdzb21lL3Rlc3QuaHRtbCBbQkFaXScp CisgICAgICAgIHNlbGYuYXNzZXJ0RXF1YWwoZXhwZWN0YXRpb24ubmFtZSwgJ3NvbWUvdGVzdC5o dG1sJykKKyAgICAgICAgc2VsZi5hc3NlcnRFcXVhbChleHBlY3RhdGlvbi5tb2RpZmllcnMsIFtd KQorICAgICAgICBzZWxmLmFzc2VydEVxdWFsKGV4cGVjdGF0aW9uLmV4cGVjdGF0aW9ucywgWydi YXonXSkKKyAgICAgICAgc2VsZi5hc3NlcnRFcXVhbChleHBlY3RhdGlvbi5jb21tZW50LCBOb25l KQorICAgICAgICBzZWxmLmFzc2VydEVxdWFsKGxlbihleHBlY3RhdGlvbi53YXJuaW5ncyksIDAp CisKKyAgICBkZWYgdGVzdF90b2tlbml6ZV9uZXdfZm9ybWF0X3dpdGhvdXRfZXhwZWN0YXRpb25z KHNlbGYpOgorICAgICAgICBleHBlY3RhdGlvbiA9IHNlbGYuX3Rva2VuaXplKCd3ZWJraXQub3Jn L2IvMTIzNDUgc29tZS90ZXN0Lmh0bWwnKQorICAgICAgICBzZWxmLmFzc2VydEVxdWFsKGV4cGVj dGF0aW9uLm5hbWUsICdzb21lL3Rlc3QuaHRtbCcpCisgICAgICAgIHNlbGYuYXNzZXJ0RXF1YWwo ZXhwZWN0YXRpb24ubW9kaWZpZXJzLCBbJ3dlYmtpdC5vcmcvYi8xMjM0NScsICdza2lwJ10pCisg ICAgICAgIHNlbGYuYXNzZXJ0RXF1YWwoZXhwZWN0YXRpb24uZXhwZWN0YXRpb25zLCBbXSkKKyAg ICAgICAgc2VsZi5hc3NlcnRFcXVhbChleHBlY3RhdGlvbi5jb21tZW50LCBOb25lKQorICAgICAg ICBzZWxmLmFzc2VydEVxdWFsKGxlbihleHBlY3RhdGlvbi53YXJuaW5ncyksIDApCisKKyAgICBk ZWYgdGVzdF90b2tlbml6ZV9uZXdfZm9ybWF0X3dpdGhfcGxhdGZvcm0oc2VsZik6CisgICAgICAg IGV4cGVjdGF0aW9uID0gc2VsZi5fdG9rZW5pemUoJ3dlYmtpdC5vcmcvYi8xMjM0NSBbV2luIE1h Y10gc29tZS90ZXN0Lmh0bWwgW1RleHRdJykKKyAgICAgICAgc2VsZi5hc3NlcnRFcXVhbChleHBl Y3RhdGlvbi5uYW1lLCAnc29tZS90ZXN0Lmh0bWwnKQorICAgICAgICBzZWxmLmFzc2VydEVxdWFs KGV4cGVjdGF0aW9uLm1vZGlmaWVycywgWyd3ZWJraXQub3JnL2IvMTIzNDUnLCAnd2luJywgJ21h YyddKQorICAgICAgICBzZWxmLmFzc2VydEVxdWFsKGV4cGVjdGF0aW9uLmV4cGVjdGF0aW9ucywg Wyd0ZXh0J10pCisgICAgICAgIHNlbGYuYXNzZXJ0RXF1YWwoZXhwZWN0YXRpb24uY29tbWVudCwg Tm9uZSkKKyAgICAgICAgc2VsZi5hc3NlcnRFcXVhbChsZW4oZXhwZWN0YXRpb24ud2FybmluZ3Mp LCAwKQorCisgICAgZGVmIHRlc3RfdG9rZW5pemVfbmV3X2Zvcm1hdF93aXRoX3dvbnRmaXhfYnVn KHNlbGYpOgorICAgICAgICBleHBlY3RhdGlvbiA9IHNlbGYuX3Rva2VuaXplKCd3ZWJraXQub3Jn L2IvMTIzNDUgc29tZS90ZXN0Lmh0bWwgW1dvbnRGaXhdJykKKyAgICAgICAgc2VsZi5hc3NlcnRF cXVhbChleHBlY3RhdGlvbi5uYW1lLCAnc29tZS90ZXN0Lmh0bWwnKQorICAgICAgICBzZWxmLmFz c2VydEVxdWFsKGV4cGVjdGF0aW9uLm1vZGlmaWVycywgWyd3ZWJraXQub3JnL2IvMTIzNDUnLCAn d29udGZpeCcsICdza2lwJ10pCisgICAgICAgIHNlbGYuYXNzZXJ0RXF1YWwoZXhwZWN0YXRpb24u ZXhwZWN0YXRpb25zLCBbXSkKKyAgICAgICAgc2VsZi5hc3NlcnRFcXVhbChleHBlY3RhdGlvbi5j b21tZW50LCBOb25lKQorICAgICAgICBzZWxmLmFzc2VydEVxdWFsKGxlbihleHBlY3RhdGlvbi53 YXJuaW5ncyksIDApCisKKyAgICBkZWYgdGVzdF90b2tlbml6ZV9uZXdfZm9ybWF0X3dpdGhfd29u dGZpeChzZWxmKToKKyAgICAgICAgZXhwZWN0YXRpb24gPSBzZWxmLl90b2tlbml6ZSgnc29tZS90 ZXN0Lmh0bWwgW1dvbnRGaXhdJykKKyAgICAgICAgc2VsZi5hc3NlcnRFcXVhbChleHBlY3RhdGlv bi5uYW1lLCAnc29tZS90ZXN0Lmh0bWwnKQorICAgICAgICBzZWxmLmFzc2VydEVxdWFsKGV4cGVj dGF0aW9uLm1vZGlmaWVycywgWyd3b250Zml4JywgJ3NraXAnXSkKKyAgICAgICAgc2VsZi5hc3Nl cnRFcXVhbChleHBlY3RhdGlvbi5leHBlY3RhdGlvbnMsIFtdKQorICAgICAgICBzZWxmLmFzc2Vy dEVxdWFsKGV4cGVjdGF0aW9uLmNvbW1lbnQsIE5vbmUpCisgICAgICAgIHNlbGYuYXNzZXJ0RXF1 YWwobGVuKGV4cGVjdGF0aW9uLndhcm5pbmdzKSwgMCkKKworICAgIGRlZiB0ZXN0X3Rva2VuaXpl X25ld19mb3JtYXRfd2l0aF9leHRyYV9hbmdsZV9icmFja2V0KHNlbGYpOgorICAgICAgICBleHBl Y3RhdGlvbiA9IHNlbGYuX3Rva2VuaXplKCdzb21lL3Rlc3QuaHRtbCBbV29udEZpeF1dJykKKyAg ICAgICAgc2VsZi5hc3NlcnRFcXVhbChleHBlY3RhdGlvbi53YXJuaW5ncywgWydGYWlsZWQgdG8g cGFyc2UnXSkKKworICAgIGRlZiB0ZXN0X3Rva2VuaXplX25ld19mb3JtYXRfd2l0aF9za2lwKHNl bGYpOgorICAgICAgICBleHBlY3RhdGlvbiA9IHNlbGYuX3Rva2VuaXplKCdzb21lL3Rlc3QuaHRt bCBbU2tpcF0nKQorICAgICAgICBzZWxmLmFzc2VydEVxdWFsKGV4cGVjdGF0aW9uLndhcm5pbmdz LCBbJ1NraXAgbW9kaWZpZXIgaGFzIGJlZW4gZGVwcmVjYXRlZCddKQorCisgICAgZGVmIHRlc3Rf dG9rZW5pemVfbmV3X2Zvcm1hdF93aXRoX3dvbnRmaXhfYW5kX290aGVyX2V4cGVjdGF0aW9uKHNl bGYpOgorICAgICAgICBleHBlY3RhdGlvbiA9IHNlbGYuX3Rva2VuaXplKCdzb21lL3Rlc3QuaHRt bCBbV29udEZpeCBJbWFnZV0nKQorICAgICAgICBzZWxmLmFzc2VydEVxdWFsKGV4cGVjdGF0aW9u Lndhcm5pbmdzLCBbJ1dvbnRGaXggc2hvdWxkIG5vdCBiZSB1c2VkIHdpdGggYW55IG90aGVyIGV4 cGVjdGF0aW9uJ10pCisKIAogY2xhc3MgVGVzdEV4cGVjdGF0aW9uU2VyaWFsaXplclRlc3RzKHVu aXR0ZXN0LlRlc3RDYXNlKToKICAgICBkZWYgX19pbml0X18oc2VsZiwgdGVzdEZ1bmMpOgo=