We currently use go-task to run tests locally (rarely), in Tugboat for CI, and on BRD in the staging post-deploy tests. We should evaluate whether Task is still the best choice for our precise use cases.
Background and Complications
We originally used a system called Yaml Tasks, which was part of Devshop. When we shifted to Tugboat, we kept Yaml Tasks around for a while, but this became troublesome with the update to Drupal 9 (see #4871). At that time, we replaced it with Task; the primary goal was a 1:1 feature parity. This involved a nontrivial amount of highly fragile and visually appalling code injected into the Taskfiles in order to get output reported with the nontraditional approaches taken to standard I/O taken by Lando, Tugboat, and BRD (via Jenkins, Ansible, etc):
So Tugboat executes a Task command on certain environments, which then uses additional tools like github-status-updater to actually report the tests' status back to GitHub.
Things to consider:
GitHub Actions should probably dispatch the individual tests. These tests should generally be parallelizable with one another; i.e. there's no reason we shouldn't be able to run PHPUnit alongside Cypress alongside Cypress-Axe alongside the test that looks for status report errors.
Cypress Dashboard might be a useful tool for gaining insight into Cypress test runs.
Capturing output from Tugboat/Jenkins/local environments is surprisingly nontrivial, so giving more proximal feedback to developers would be awesome and clean up the codebase.
Acceptance Criteria
[ ] Decisions have been made for running and retrieving success/failure and relevant output from
[ ] local test runs
[ ] Tugboat test runs
[ ] staging post-deploy test runs
[ ] followup tickets have been opened to address the outcomes of these decisions
CMS Team
Please check the team(s) that will do this work.
[ ] Sitewide program
[ ] Platform CMS Team
[ ] Sitewide crew (leave Sitewide unchecked and check the specific team instead)
Description
We currently use go-task to run tests locally (rarely), in Tugboat for CI, and on BRD in the staging post-deploy tests. We should evaluate whether Task is still the best choice for our precise use cases.
Background and Complications
We originally used a system called Yaml Tasks, which was part of Devshop. When we shifted to Tugboat, we kept Yaml Tasks around for a while, but this became troublesome with the update to Drupal 9 (see #4871). At that time, we replaced it with Task; the primary goal was a 1:1 feature parity. This involved a nontrivial amount of highly fragile and visually appalling code injected into the Taskfiles in order to get output reported with the nontraditional approaches taken to standard I/O taken by Lando, Tugboat, and BRD (via Jenkins, Ansible, etc):
So Tugboat executes a Task command on certain environments, which then uses additional tools like
github-status-updater
to actually report the tests' status back to GitHub.Things to consider:
Acceptance Criteria
CMS Team
Please check the team(s) that will do this work.
Sitewide program
Platform CMS Team
Sitewide crew
(leave Sitewide unchecked and check the specific team instead)⭐️ Content ops
⭐️ CMS experience
⭐️ Public websites
⭐️ Facilities
⭐️ User support