20fb5b0b3c9eb48c3e0eed76c2be90893d0179e2: Bug 1397503 - Vary cache name when using out-of-tree Docker images; r?dustin draft
Gregory Szorc <gps@mozilla.com> - Wed, 06 Sep 2017 16:09:15 -0700 - rev 660428
Push 78400 by gszorc@mozilla.com at Wed, 06 Sep 2017 23:39:19 +0000
Bug 1397503 - Vary cache name when using out-of-tree Docker images; r?dustin We currently vary the cache name for run-task tasks whenever run-task changes. This allows us to not worry about backwards or forwards compatibility of caches in run-task tasks. This strategy doesn't work for out-of-tree Docker images because the content of run-task cannot be determined at Taskgraph time: the content of run-task was determined when that Docker image was built and there is no way to get that content efficiently during Taskgraph. So, for out-of-tree Docker images we now vary the cache name by the Docker image name. This means that out-of-tree run-task tasks will get separate caches for each a) Docker image b) Docker image version. This isn't ideal. Ideally we would share caches if run-task doesn't change between Docker image. But without any way of proving that at Taskgraph time, we take the safe road and force cache separation. MozReview-Commit-ID: FMiQBqfvjqW
5393c21a4ca0ad487d494c74bc9e251c9b248a53: Bug 1397503 - Perform cache sanitization for image_builder tasks; r?dustin draft
Gregory Szorc <gps@mozilla.com> - Wed, 06 Sep 2017 15:35:13 -0700 - rev 660427
Push 78400 by gszorc@mozilla.com at Wed, 06 Sep 2017 23:39:19 +0000
Bug 1397503 - Perform cache sanitization for image_builder tasks; r?dustin The image_builder Docker image doesn't set a "command" in its task definition. The image instead relies on a RUN in its Dockerfile to control the started command. This command is a shell script which eventually runs run-task. This all means that image_builder tasks are executing run-task but the cache sanitization implemented in bug 1391476 isn't getting applied to those tasks. This means run-task could barf due to constraint violations due to improperly configured caches. The fix for this is to teach the generic task transform that image_builder tasks use run-task. The effect of this is that some environment variables get set and the cache name changes depending on the contents of run-task. MozReview-Commit-ID: IFqsDxD0eDh
aa111fa81f1a3343e6b9092208fb42b0d39b187f: Bug 1397530 - report all exceptions checking the account status. r?eoger draft
Mark Hammond <mhammond@skippinet.com.au> - Thu, 07 Sep 2017 09:35:47 +1000 - rev 660426
Push 78399 by bmo:markh@mozilla.com at Wed, 06 Sep 2017 23:37:29 +0000
Bug 1397530 - report all exceptions checking the account status. r?eoger MozReview-Commit-ID: ClCaDhgdQ0a
1b7a74fcb783345aac7bf602e30788bef5bc789a: Bug 1397503 - Vary cache name when using out-of-tree Docker images; r?dustin draft
Gregory Szorc <gps@mozilla.com> - Wed, 06 Sep 2017 16:09:15 -0700 - rev 660425
Push 78398 by gszorc@mozilla.com at Wed, 06 Sep 2017 23:36:56 +0000
Bug 1397503 - Vary cache name when using out-of-tree Docker images; r?dustin We currently vary the cache name for run-task tasks whenever run-task changes. This allows us to not worry about backwards or forwards compatibility of caches in run-task tasks. This strategy doesn't work for out-of-tree Docker images because the content of run-task cannot be determined at Taskgraph time: the content of run-task was determined when that Docker image was built and there is no way to get that content efficiently during Taskgraph. So, for out-of-tree Docker images we now vary the cache name by the Docker image name. This means that out-of-tree run-task tasks will get separate caches for each a) Docker image b) Docker image version. This isn't ideal. Ideally we would share caches if run-task doesn't change between Docker image. But without any way of proving that at Taskgraph time, we take the safe road and force cache separation. MozReview-Commit-ID: FMiQBqfvjqW
a098c48fae4cdbc92926a1e3b1f1508dc92edd59: Bug 1397503 - Perform cache sanitization for image_builder tasks; r?dustin draft
Gregory Szorc <gps@mozilla.com> - Wed, 06 Sep 2017 15:35:13 -0700 - rev 660424
Push 78398 by gszorc@mozilla.com at Wed, 06 Sep 2017 23:36:56 +0000
Bug 1397503 - Perform cache sanitization for image_builder tasks; r?dustin The image_builder Docker image doesn't set a "command" in its task definition. The image instead relies on a RUN in its Dockerfile to control the started command. This command is a shell script which eventually runs run-task. This all means that image_builder tasks are executing run-task but the cache sanitization implemented in bug 1391476 isn't getting applied to those tasks. This means run-task could barf due to constraint violations due to improperly configured caches. The fix for this is to teach the generic task transform that image_builder tasks use run-task. The effect of this is that some environment variables get set and the cache name changes depending on the contents of run-task. MozReview-Commit-ID: IFqsDxD0eDh
cb753e1f189b2fd1f725bc1c9fe127ca62d0a9d8: Bug 1341504 - Don't disable incremental linking when optimizations are turned off. r?ted draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Sat, 02 Sep 2017 03:03:08 +0200 - rev 660423
Push 78397 by bmo:jyavenard@mozilla.com at Wed, 06 Sep 2017 23:35:18 +0000
Bug 1341504 - Don't disable incremental linking when optimizations are turned off. r?ted Incremental linking is automatically disabled when -OPT:REF or -OPT:ICF are used. Seeing that we're disabling optimizations anyway, may as well not use those linker flags as they considerably slow down linking. MozReview-Commit-ID: 9OXG19uxeI9
d8e238b811d3dc74515065ae8cab6c74baf0295f: Merge autoland to central, a=merge
Wes Kocher <wkocher@mozilla.com> - Wed, 06 Sep 2017 15:51:25 -0700 - rev 660422
Push 78397 by bmo:jyavenard@mozilla.com at Wed, 06 Sep 2017 23:35:18 +0000
Merge autoland to central, a=merge MozReview-Commit-ID: GQpNetIXsWP
1f9c31f60c29d61d96f1ede3dbf76bb561adeed2: Bug 1397503 - Vary cache name when using out-of-tree Docker images; r?dustin draft
Gregory Szorc <gps@mozilla.com> - Wed, 06 Sep 2017 16:09:15 -0700 - rev 660421
Push 78396 by gszorc@mozilla.com at Wed, 06 Sep 2017 23:31:52 +0000
Bug 1397503 - Vary cache name when using out-of-tree Docker images; r?dustin We currently vary the cache name for run-task tasks whenever run-task changes. This allows us to not worry about backwards or forwards compatibility of caches in run-task tasks. This strategy doesn't work for out-of-tree Docker images because the content of run-task cannot be determined at Taskgraph time: the content of run-task was determined when that Docker image was built and there is no way to get that content efficiently during Taskgraph. So, for out-of-tree Docker images we now vary the cache name by the Docker image name. This means that out-of-tree run-task tasks will get separate caches for each a) Docker image b) Docker image version. This isn't ideal. Ideally we would share caches if run-task doesn't change between Docker image. But without any way of proving that at Taskgraph time, we take the safe road and force cache separation. MozReview-Commit-ID: FMiQBqfvjqW
2820ac7f60c2564d850eb983c10bbbf8a7162558: Bug 1397503 - Perform cache sanitization for image_builder tasks; r?dustin draft
Gregory Szorc <gps@mozilla.com> - Wed, 06 Sep 2017 15:35:13 -0700 - rev 660420
Push 78396 by gszorc@mozilla.com at Wed, 06 Sep 2017 23:31:52 +0000
Bug 1397503 - Perform cache sanitization for image_builder tasks; r?dustin The image_builder Docker image doesn't set a "command" in its task definition. The image instead relies on a RUN in its Dockerfile to control the started command. This command is a shell script which eventually runs run-task. This all means that image_builder tasks are executing run-task but the cache sanitization implemented in bug 1391476 isn't getting applied to those tasks. This means run-task could barf due to constraint violations due to improperly configured caches. The fix for this is to teach the generic task transform that image_builder tasks use run-task. The effect of this is that some environment variables get set and the cache name changes depending on the contents of run-task. MozReview-Commit-ID: IFqsDxD0eDh
74ab64306b2d3b3bfe0467ba122123232a446fcf: Bug 1393497 - remove Valence from WebIDE; r=ochameau draft
ZER0 <zer0.kaos@gmail.com> - Thu, 07 Sep 2017 01:22:58 +0200 - rev 660419
Push 78395 by bmo:zer0@mozilla.com at Wed, 06 Sep 2017 23:24:01 +0000
Bug 1393497 - remove Valence from WebIDE; r=ochameau MozReview-Commit-ID: 9mEhpfIFo7n
8cbea12f0dbe6ed89be1dfc9878c886e8adfe783: Bug 1397503 - Vary cache name when using out-of-tree Docker images; r?dustin draft
Gregory Szorc <gps@mozilla.com> - Wed, 06 Sep 2017 16:09:15 -0700 - rev 660418
Push 78394 by gszorc@mozilla.com at Wed, 06 Sep 2017 23:22:14 +0000
Bug 1397503 - Vary cache name when using out-of-tree Docker images; r?dustin We currently vary the cache name for run-task tasks whenever run-task changes. This allows us to not worry about backwards or forwards compatibility of caches in run-task tasks. This strategy doesn't work for out-of-tree Docker images because the content of run-task cannot be determined at Taskgraph time: the content of run-task was determined when that Docker image was built and there is no way to get that content efficiently during Taskgraph. So, for out-of-tree Docker images we now vary the cache name by the Docker image name. This means that out-of-tree run-task tasks will get separate caches for each a) Docker image b) Docker image version. This isn't ideal. Ideally we would share caches if run-task doesn't change between Docker image. But without any way of proving that at Taskgraph time, we take the safe road and force cache separation. MozReview-Commit-ID: FMiQBqfvjqW
84d3c2e49650dca8468b8abf1c0ccae4873fbbad: Bug 1397503 - Perform cache sanitization for image_builder tasks; r?dustin draft
Gregory Szorc <gps@mozilla.com> - Wed, 06 Sep 2017 15:35:13 -0700 - rev 660417
Push 78394 by gszorc@mozilla.com at Wed, 06 Sep 2017 23:22:14 +0000
Bug 1397503 - Perform cache sanitization for image_builder tasks; r?dustin The image_builder Docker image doesn't set a "command" in its task definition. The image instead relies on a RUN in its Dockerfile to control the started command. This command is a shell script which eventually runs run-task. This all means that image_builder tasks are executing run-task but the cache sanitization implemented in bug 1391476 isn't getting applied to those tasks. This means run-task could barf due to constraint violations due to improperly configured caches. The fix for this is to teach the generic task transform that image_builder tasks use run-task. The effect of this is that some environment variables get set and the cache name changes depending on the contents of run-task. MozReview-Commit-ID: IFqsDxD0eDh
1cc431bfcea4302964b433f43b476882e7b35b81: Bug 1377587 - Always act like __exposedProps__ is missing. draft
Andrew McCreight <continuation@gmail.com> - Tue, 22 Aug 2017 14:24:11 -0700 - rev 660416
Push 78393 by bmo:continuation@gmail.com at Wed, 06 Sep 2017 23:14:12 +0000
Bug 1377587 - Always act like __exposedProps__ is missing. This patch gently removes support for __exposedProps__ by changing ExposedPropertiesOnly::check() to always return false, while still failing silently in deny for some kinds of access. The tests that I changed all involve testing the behavior with __exposedProps__. I adjusted them to expect it to fail, or to adjust the error message they get when they fail. That seemed better than deleting them entirely. Note that test_bug1065185.html had a bug, so that it never executed the first case. I fixed that, and then fixed up the test to work when __exposedProps__ is not supported. This also removes various bits of the test framework that use __exposedProps__, but don't actually need to. MozReview-Commit-ID: 8fvkAmITmXY
e97237bdf2d799e9788b54c0379bd1b2a15d0546: Bug 1397460 - Don't throw for a failure in cpows_child.js. r=billm draft
Andrew McCreight <continuation@gmail.com> - Wed, 06 Sep 2017 13:45:22 -0700 - rev 660415
Push 78393 by bmo:continuation@gmail.com at Wed, 06 Sep 2017 23:14:12 +0000
Bug 1397460 - Don't throw for a failure in cpows_child.js. r=billm When ok() is passed false, we send a message to the parent, which will cause the test to fail. Throwing in this helper in the child just makes the test hang for a while. MozReview-Commit-ID: 4gwBACPYfDO
469e63eff8941b9de5abdc9716d68a025c466dd5: Bug 1395322 Part 3: Change timeouts to failures in layout/style/test/chrome/test_stylesheet_clone_import_rule.html. draft
Brad Werth <bwerth@mozilla.com> - Wed, 30 Aug 2017 13:10:42 -0700 - rev 660414
Push 78392 by bwerth@mozilla.com at Wed, 06 Sep 2017 23:12:35 +0000
Bug 1395322 Part 3: Change timeouts to failures in layout/style/test/chrome/test_stylesheet_clone_import_rule.html. MozReview-Commit-ID: 8ea7J5ExmzH
d20b7b3a203bb0b65d056e5c6f2c4bb2fbb6a6d1: Bug 1395322 Part 2: Make ServoCSSRuleList::InsertRule map DOMCSSRule types to Rule types. draft
Brad Werth <bwerth@mozilla.com> - Wed, 06 Sep 2017 16:11:11 -0700 - rev 660413
Push 78392 by bwerth@mozilla.com at Wed, 06 Sep 2017 23:12:35 +0000
Bug 1395322 Part 2: Make ServoCSSRuleList::InsertRule map DOMCSSRule types to Rule types. MozReview-Commit-ID: 9lvQLsQItEy
9da3a0e54eee784e724d397cdeafbc2b3aebbf82: Bug 1395322 Part 1: Add a mapping function from nsIDOMCSSRule type enum to Rule type enum. draft
Brad Werth <bwerth@mozilla.com> - Wed, 06 Sep 2017 16:05:12 -0700 - rev 660412
Push 78392 by bwerth@mozilla.com at Wed, 06 Sep 2017 23:12:35 +0000
Bug 1395322 Part 1: Add a mapping function from nsIDOMCSSRule type enum to Rule type enum. MozReview-Commit-ID: 7ocyE3RQnOG
cf46f868733c9e1e31b30f1399fe78451640317e: Bug 1392143 - P3. Retry the readback after relocating the window to (0,0). r?mattwoodrow draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 06 Sep 2017 18:59:07 +0200 - rev 660411
Push 78391 by bmo:jyavenard@mozilla.com at Wed, 06 Sep 2017 23:07:16 +0000
Bug 1392143 - P3. Retry the readback after relocating the window to (0,0). r?mattwoodrow This is a workaround until bug 1397253 is resolved. MozReview-Commit-ID: I3jLkbPRNE4
7a5a63ff39d6762a177a93493cba7238f388ffa4: Bug 1392143 - P2. Disable hardware decoding for small videos. r?mattwoodrow draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 06 Sep 2017 17:02:21 +0200 - rev 660410
Push 78391 by bmo:jyavenard@mozilla.com at Wed, 06 Sep 2017 23:07:16 +0000
Bug 1392143 - P2. Disable hardware decoding for small videos. r?mattwoodrow As the H264 SanityTest uses a 132x132 videos to determine if the hardware decoder is working, we always use the software decoder for smaller videos. MozReview-Commit-ID: 8VbZTiJO9mA
90d44fbe289becba8ee174466cc9bd1e2d086db5: Bug 1392143 - P1. Change video size used for testing if h264 decoder is working. r?mattwoodrow draft
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 06 Sep 2017 15:42:46 +0200 - rev 660409
Push 78391 by bmo:jyavenard@mozilla.com at Wed, 06 Sep 2017 23:07:16 +0000
Bug 1392143 - P1. Change video size used for testing if h264 decoder is working. r?mattwoodrow AMD incorrectly decode videos with a resolution that is less than 128x128, as such with the test failing we disable hardware decoding on those machines, even though other resolutions work well. So we use a 132x132 video instead. MozReview-Commit-ID: 80mk11CNsil
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip