build(deps): bump taskcluster from 53.0.0 to 53.1.0

[dependabot]

Bumps taskcluster from 53.0.0 to 53.1.0.

Release notes

Sourced from taskcluster's releases.

v53.1.0

USERS

▶ [minor] #5994 Generic Worker: Adds task.payload.feature.loopbackVideo for loopback video device support on Linux.

The v4l2loopback kernel module must be installed on the host system for this feature to work, although it does not need to be loaded. Generic Worker loads the module with modprobe and generates the virtual video device with a v4l2loopback command. Under the multiuser engine, it also manages file ownership of the device with chown to ensure that only tasks with suitable scopes have read/write access to the virtual device.

For tasks that enable the feature, the virtual video device location will be provided to the task commands via the environment variable TASKCLUSTER_VIDEO_DEVICE. The value of the environment variable depends on deployment configuration, and therefore tasks should not assume a fixed value. Its value will however take the form /dev/video<DEVICE_NUMBER> where <DEVICE_NUMBER> is an integer between 0 and 255. The Generic Worker config setting loopbackVideoDeviceNumber may be used to change the device number. Future releases of Generic Worker may provide the capability of having more than one virtual video device; currently only one virtual video device is supported.

▶ [patch] #6326 Running taskcluster group list without a task group ID now outputs error message:

Error: list expects argument <taskGroupId>

Previously, it incorrectly outputted:

Error: list expects argument <taskId>

Changelog

Sourced from taskcluster's changelog.

v53.1.0

USERS

▶ [minor] #5994 Generic Worker: Adds task.payload.feature.loopbackVideo for loopback video device support on Linux.

The v4l2loopback kernel module must be installed on the host system for this feature to work, although it does not need to be loaded. Generic Worker loads the module with modprobe and generates the virtual video device with a v4l2loopback command. Under the multiuser engine, it also manages file ownership of the device with chown to ensure that only tasks with suitable scopes have read/write access to the virtual device.

For tasks that enable the feature, the virtual video device location will be provided to the task commands via the environment variable TASKCLUSTER_VIDEO_DEVICE. The value of the environment variable depends on deployment configuration, and therefore tasks should not assume a fixed value. Its value will however take the form /dev/video<DEVICE_NUMBER> where <DEVICE_NUMBER> is an integer between 0 and 255. The Generic Worker config setting loopbackVideoDeviceNumber may be used to change the device number. Future releases of Generic Worker may provide the capability of having more than one virtual video device; currently only one virtual video device is supported.

▶ [patch] #6326 Running taskcluster group list without a task group ID now outputs error message:

Error: list expects argument <taskGroupId>

Previously, it incorrectly outputted:

Error: list expects argument <taskId>

Commits

• 9af952e v53.1.0
• e2fd9f6 Merge pull request #6331 from taskcluster/matt-boris/loopbackVideoGenericWorker
• 82863db Add tests and update to use device number from config
• c9cb7f2 Address some PR comments
• bb7ceed Apply suggestions from code review
• 81f83e1 Test for video device and env var presence
• e4b3ac8 Update task timeouts for building/testing/linting gw
• 96e5b3c Address PR comments and add some initial tests
• 88f5ddb feat(generic-worker): add loopbackVideo support
• e8e9d27 Merge pull request #6327 from taskcluster/issue6326
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)