6e0f5055d56f8246db083550c08b73890eacbc9a: Bug 1288311 - Extend VIDEO_CAN_CREATE_*_DECODER telemetry probes. r?francois draft
Chris Pearce <cpearce@mozilla.com> - Thu, 21 Jul 2016 16:09:42 +1200 - rev 391016
Push 23786 by cpearce@mozilla.com at Fri, 22 Jul 2016 01:27:51 +0000
Bug 1288311 - Extend VIDEO_CAN_CREATE_*_DECODER telemetry probes. r?francois We're actively trying to encourage people to install Windows system decoders to drive the "can't create" number to 0. So we need this probe to measure our progress. MozReview-Commit-ID: BDE7nbaK4NX
467049c33ff6611e0cc0b7f26443d2db8d84c963: Bug 1288311 - Remove GMP install failed/unsupported telemetry reporting code. r?spohl draft
Chris Pearce <cpearce@mozilla.com> - Thu, 21 Jul 2016 16:31:56 +1200 - rev 391015
Push 23785 by cpearce@mozilla.com at Fri, 22 Jul 2016 01:22:52 +0000
Bug 1288311 - Remove GMP install failed/unsupported telemetry reporting code. r?spohl The telemetry result indicate that unexplained install failures are very rare, so we don't need to bother keeping this probe. We should still need to check whether the GMP files disappear from disk, as telemetry indicates this does happen, though quite rarely. MozReview-Commit-ID: K64tlRajACJ
121dd1acc052a4e48afe71d03a8f4fdd68f33e1a: Bug 1288311 - Remove GMP unsupported/installation failure telemetry probes. r?francois draft
Chris Pearce <cpearce@mozilla.com> - Thu, 21 Jul 2016 16:16:51 +1200 - rev 391014
Push 23785 by cpearce@mozilla.com at Fri, 22 Jul 2016 01:22:52 +0000
Bug 1288311 - Remove GMP unsupported/installation failure telemetry probes. r?francois MozReview-Commit-ID: Jnh2Od6jV2X
d4de520907e495143ed44fe22476eebf5012d36d: Bug 1288311 - Extend VIDEO_CAN_CREATE_*_DECODER telemetry probes. r?francois draft
Chris Pearce <cpearce@mozilla.com> - Thu, 21 Jul 2016 16:09:42 +1200 - rev 391013
Push 23785 by cpearce@mozilla.com at Fri, 22 Jul 2016 01:22:52 +0000
Bug 1288311 - Extend VIDEO_CAN_CREATE_*_DECODER telemetry probes. r?francois MozReview-Commit-ID: BDE7nbaK4NX
a4ec9aeaa1044ef57e2836d2269c80eb24dd493c: Bug 798223 - Increase optimized favicon dimension in Places database from 16 to 32. r?mak draft
Drew Willcoxon <adw@mozilla.com> - Thu, 21 Jul 2016 17:53:08 -0700 - rev 391012
Push 23784 by dwillcoxon@mozilla.com at Fri, 22 Jul 2016 00:53:28 +0000
Bug 798223 - Increase optimized favicon dimension in Places database from 16 to 32. r?mak MozReview-Commit-ID: HTLPQR66HOn
e7059aff26e0665c5b82766e2cbeb42a90163237: Bug 1287725 - Drop KeyframeEffectReadOnly::HasAnimationOfProperties and nsLayoutUtils::HasCurrentAnimationsForProperties. r?birtles draft
Hiroyuki Ikezoe <hiikezoe@mozilla-japan.org> - Fri, 22 Jul 2016 07:13:36 +0900 - rev 391011
Push 23783 by hiikezoe@mozilla-japan.org at Fri, 22 Jul 2016 00:48:41 +0000
Bug 1287725 - Drop KeyframeEffectReadOnly::HasAnimationOfProperties and nsLayoutUtils::HasCurrentAnimationsForProperties. r?birtles MozReview-Commit-ID: KfDK49BK2yG
3f9f417a3573d206a56c9cf3a5a99b3edbec450a: Bug 1287653 - Use ImageBridge d3d device. - r=jrmuizel draft
Jeff Gilbert <jdashg@gmail.com> - Tue, 19 Jul 2016 13:46:59 -0700 - rev 391010
Push 23782 by bmo:jgilbert@mozilla.com at Fri, 22 Jul 2016 00:22:41 +0000
Bug 1287653 - Use ImageBridge d3d device. - r=jrmuizel Using the context device causes crashes in the driver. MozReview-Commit-ID: GYKMBpJ21u0
2ac5c328a47d2d5120be2b70b4b67c05c3d2bfec: Bug 1287653 - Minor fixes to DoesD3D11TextureSharingWorkInternal. - r=jrmuizel draft
Jeff Gilbert <jgilbert@mozilla.com> - Sun, 17 Jul 2016 13:54:23 -0700 - rev 391009
Push 23782 by bmo:jgilbert@mozilla.com at Fri, 22 Jul 2016 00:22:41 +0000
Bug 1287653 - Minor fixes to DoesD3D11TextureSharingWorkInternal. - r=jrmuizel MozReview-Commit-ID: l8VkUewdhA
4c43a7a2c2d67e7b2749278ba827656efe065da6: Bug 1287653 - Remove context sharing from WGL. - r=mtseng draft
Jeff Gilbert <jgilbert@mozilla.com> - Sun, 17 Jul 2016 14:49:55 -0700 - rev 391008
Push 23782 by bmo:jgilbert@mozilla.com at Fri, 22 Jul 2016 00:22:41 +0000
Bug 1287653 - Remove context sharing from WGL. - r=mtseng MozReview-Commit-ID: 2CJovqWwAGB
4405c004875a29ec465bc0c398cc03d8b9807b5e: Bug 1287653 - Cleanup GLContextProviderWGL. - r=mtseng draft
Jeff Gilbert <jgilbert@mozilla.com> - Sun, 17 Jul 2016 14:42:47 -0700 - rev 391007
Push 23782 by bmo:jgilbert@mozilla.com at Fri, 22 Jul 2016 00:22:41 +0000
Bug 1287653 - Cleanup GLContextProviderWGL. - r=mtseng MozReview-Commit-ID: KTM77i36mN
b837653bde0ff45d99917c9c2ea462b41dde4d0b: Bug 1287653 - AMD associates DXOpenDevice with the current GL context. - r=mtseng draft
Jeff Gilbert <jgilbert@mozilla.com> - Sun, 17 Jul 2016 14:32:34 -0700 - rev 391006
Push 23782 by bmo:jgilbert@mozilla.com at Fri, 22 Jul 2016 00:22:41 +0000
Bug 1287653 - AMD associates DXOpenDevice with the current GL context. - r=mtseng MozReview-Commit-ID: 7Rv7HbOxLil
d747dafd2f5b53d95e35a583556661faf92a9eba: Bug 1287653 - Pull out d3d11 creation flags into local for better readability and editability. - r=jrmuizel draft
Jeff Gilbert <jgilbert@mozilla.com> - Sun, 17 Jul 2016 14:25:43 -0700 - rev 391005
Push 23782 by bmo:jgilbert@mozilla.com at Fri, 22 Jul 2016 00:22:41 +0000
Bug 1287653 - Pull out d3d11 creation flags into local for better readability and editability. - r=jrmuizel MozReview-Commit-ID: BVtEL6mL4pL
5a7d9d67a494120880203a6e141f98b34b8daee0: Bug 1288567 - Add special Dockerfile syntax to add arbitrary files to context draft
Gregory Szorc <gps@mozilla.com> - Thu, 21 Jul 2016 16:51:30 -0700 - rev 391004
Push 23781 by bmo:gps@mozilla.com at Thu, 21 Jul 2016 23:53:37 +0000
Bug 1288567 - Add special Dockerfile syntax to add arbitrary files to context A limitation of traditional `docker build` is that it only has access to files in the same directory as the Dockerfile. Typically, when you do `docker build`, Docker will create a tar archive of all files in the same directory as the Dockerfile and upload that to Docker and the image building process will have access to all files in the archive. Over a year ago, I realized you could write some code to create custom context archives and talk to the Docker build API directly to use your custom archive. I hacked some code into version-control-tools that parsed Dockerfiles for special syntax denoting extra paths from the source checkout to add to the context and proceed to add them to context archives. This commit essentially copied that code for use by taskgraph's built-in Docker image building. Using the syntax "# %include <path>" you are able to include paths or directories (relative from the top source directory root) in the generated context archive. Files add this way are available under the "topsrcdir/" path. The "lint" image has been changed to use this syntax to add in in-tree version of tooltool.py (instead of downloading from github.com). This eliminates a dependency on a third party service and increases security and determinism. Yay. In order to write tests, I had to make archiving deterministic. That's why we no longer use a single "tar.add()" for the Dockerfile directory. Instead, we obtain the list of files up front, sort them, then add with uid/gid set to 0, so uid/gid is consistent no matter what it is on the filesystem performing context creation. More determinism, yay. I would like to test this feature a bit more. However, the test environment for custom Docker image building doesn't currently facilitate custom source paths: it expects Docker files to be in $topsrcdir/testing/docker. If we add more functionality to this, we should definitely invest in writing better tests. MozReview-Commit-ID: 4hPZesJuGQV
815703c4cca424cb26c988393317af6bf319160a: HACK use personal registry for Docker images draft
Gregory Szorc <gps@mozilla.com> - Thu, 21 Jul 2016 12:12:28 -0700 - rev 391003
Push 23781 by bmo:gps@mozilla.com at Thu, 21 Jul 2016 23:53:37 +0000
HACK use personal registry for Docker images MozReview-Commit-ID: Er4iHUCQsLe
2bef23d5a0bf719cd32527eb686efd87864fdaee: Bug 1247168 - Add special Dockerfile syntax to add arbitrary files to context; r?dustin draft
Gregory Szorc <gps@mozilla.com> - Thu, 21 Jul 2016 16:31:11 -0700 - rev 391002
Push 23780 by bmo:gps@mozilla.com at Thu, 21 Jul 2016 23:31:47 +0000
Bug 1247168 - Add special Dockerfile syntax to add arbitrary files to context; r?dustin A limitation of traditional `docker build` is that it only has access to files in the same directory as the Dockerfile. Typically, when you do `docker build`, Docker will create a tar archive of all files in the same directory as the Dockerfile and upload that to Docker and the image building process will have access to all files in the archive. Over a year ago, I realized you could write some code to create custom context archives and talk to the Docker build API directly to use your custom archive. I hacked some code into version-control-tools that parsed Dockerfiles for special syntax denoting extra paths from the source checkout to add to the context and proceed to add them to context archives. This commit essentially copied that code for use by taskgraph's built-in Docker image building. Using the syntax "# %include <path>" you are able to include paths or directories (relative from the top source directory root) in the generated context archive. Files add this way are available under the "topsrcdir/" path. The "lint" image has been changed to use this syntax to add in in-tree version of tooltool.py (instead of downloading from github.com). This eliminates a dependency on a third party service and increases security and determinism. Yay. In order to write tests, I had to make archiving deterministic. That's why we no longer use a single "tar.add()" for the Dockerfile directory. Instead, we obtain the list of files up front, sort them, then add with uid/gid set to 0, so uid/gid is consistent no matter what it is on the filesystem performing context creation. More determinism, yay. I would like to test this feature a bit more. However, the test environment for custom Docker image building doesn't currently facilitate custom source paths: it expects Docker files to be in $topsrcdir/testing/docker. If we add more functionality to this, we should definitely invest in writing better tests. MozReview-Commit-ID: 4hPZesJuGQV
778c94f8fe480b82fad5e517bd18b9aabdd69041: Bug 1247168 - Use a cache for repo checkout in lint tasks; r?dustin draft
Gregory Szorc <gps@mozilla.com> - Wed, 20 Jul 2016 16:21:46 -0700 - rev 391001
Push 23780 by bmo:gps@mozilla.com at Thu, 21 Jul 2016 23:31:47 +0000
Bug 1247168 - Use a cache for repo checkout in lint tasks; r?dustin Previously, every lint task would have to create its own checkout. This was time consuming. The robustcheckout extension purges the working copy of *all* untracked and ignored files. It also restores modified files to their original state. In other words, as long as you trust Mercurial to go from revision X to revision Y, robustcheckout is as good as a fresh checkout. This commit adds a cache for the working directory checkout so lint tasks only have to effectively perform incremental `hg update` between task executions. This should make tasks spend a lot less time doing version control foo. On Try, time for flake8 tasks is currently hovering around 4 minutes. After this change, I've seen tasks finish as quickly as 11s! But that was with a hacked up legacy.py that added the workspace cache to the whitelist for Try. While I would like to see workspace reuse on Try eventually, this is not the right commit to roll that out in. MozReview-Commit-ID: 66P2rt896qE
87a1e13545ad29e020cf90307250487d88543f73: Bug 1247168 - Convert lint image and tasks to use robustcheckout; r?dustin draft
Gregory Szorc <gps@mozilla.com> - Tue, 19 Jul 2016 13:30:03 -0700 - rev 391000
Push 23780 by bmo:gps@mozilla.com at Thu, 21 Jul 2016 23:31:47 +0000
Bug 1247168 - Convert lint image and tasks to use robustcheckout; r?dustin The robustcheckout Mercurial extension does a clone+checkout optimally. Read the bug for more on it. robustcheckout is already used by mozharness automation. It has resulted in a significant reduction in I/O usage and utilization in automation. This commit replaces tc-vcs with the robustcheckout equivalent. We replace the existing tc-vcs scope and cache with a new one. Because Dustin and I are paranoid, we maintain separate caches per SCM level - even though we could arguably share the same cache. Defense in depth. Robustcheckout (when used with --sharebase) pools storage for related repos automatically. i.e. changesets from inbound and central will be in the same store. This means you likely only have one copy of each changeset per cache. This can result in significant space savings. And, since there are fewer copies floating around, hg.mozilla.org and various network appliances are working less too! Since tc-vcs is no longer used, we stop it from being installed. While we're here, we also change the images to execute as the "worker" user. This happens automatically as a result of using the "checkout-and-run" script. MozReview-Commit-ID: EDeebuP7TkT
661c980289154c85f31445c36e17b12c88e83afb: Bug 1247168 - Add a script to perform a checkout then run a command; r?dustin draft
Gregory Szorc <gps@mozilla.com> - Thu, 21 Jul 2016 14:57:37 -0700 - rev 390999
Push 23780 by bmo:gps@mozilla.com at Thu, 21 Jul 2016 23:31:47 +0000
Bug 1247168 - Add a script to perform a checkout then run a command; r?dustin The script will be used as the main command in task YAML files. It changes ownership of caches. Then switches to the "worker" user. Then performs a Gecko checkout. Then executes whatever command was requested via its arguments. MozReview-Commit-ID: Fuy1VrdSGYn
b64919e71128b0cd3a1129af56f915ffa5d2025b: Bug 1278198 - Enforce codecs match the capability and content type in GetSupportedCapabilities(). r=gerald draft
Chris Pearce <cpearce@mozilla.com> - Thu, 21 Jul 2016 19:22:59 +1200 - rev 390998
Push 23779 by cpearce@mozilla.com at Thu, 21 Jul 2016 22:43:31 +0000
Bug 1278198 - Enforce codecs match the capability and content type in GetSupportedCapabilities(). r=gerald We're supposed to reject MediaKeySystemCapabilities which have a contentType that has codecs which don't match their major type, i.e. audio codecs in a video container type. I missed that, and it's causing us to fail the test_eme_requestMediaKeySystemAccess case "MP4 video container with both audio and video codec type in videoType". MozReview-Commit-ID: KQVGk9hX3eC
f944a40e2287c7a7dd01a2fb145a9e5882dd2368: Bug 1278198 - Adapt Adobe GMP's obsolete GMPDecryptor interface to new interface. r=gerald draft
Chris Pearce <cpearce@mozilla.com> - Thu, 14 Jul 2016 13:33:48 +1200 - rev 390997
Push 23779 by cpearce@mozilla.com at Thu, 21 Jul 2016 22:43:31 +0000
Bug 1278198 - Adapt Adobe GMP's obsolete GMPDecryptor interface to new interface. r=gerald The Adobe GMP only supports up to GMPDecryptor version 7. We're now up to version 9. So we need to provide an adaptor to convert the old version to run with the new interface. MozReview-Commit-ID: 5dKreev7JMv
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip