Check "Status Report" page

[mrdavidburns]

For all pull requests and deployments we check the /admin/reports/status page to make sure we're not introducing new things to be fixed.

For example: we may start a project where there are 5 warnings of things that should be fixed. We want to make sure we're not introducing more warnings as we maintain the site. If anything we want to reduce the number of warnings.

[YesCT]

This could also be an e2e test that runs using the CI using same ddev build as other e2e tests.

[deviantintegral]

I think this is probably easiest and fastest using drush's JSON output, rather than browsing and parsing the status report HTML page.

[beto-aveiga]

For example: we may start a project where there are 5 warnings of things that should be fixed.

I'm wondering where would we store this initial/base number.
We can check for errors with Drush as @deviantintegral mentioned, but how could we store that number?

[deviantintegral]

I think rather than storing a count, we could have a known-issues list that's committed to the repo, like we've done with security issues awaiting patches.

[beto-aveiga]

like we've done with security issues awaiting patches.

@deviantintegral is this in the Drainpipe's repo?

Because this is constrained to Tugboat, we may not need to store the "Status Report" result in our repo.
I imagine we would have a GitHub action to do something like the following:

• Generate our own drush status-report --format json (store it at /sites/default/files/drainpipe/status-report.json)
• Get the base preview URL or the default preview URL
• Get the base/default preview file at /sites/default/files/drainpipe/status-report.json
• Compare both Status Report files and fail PR check if there is a new record with severity "Warning" or "Error" (the threshold for failing the check could be adjusted in composer.json)
• Adding or not this Github action can be done through Composer settings (to install it when running composer install).

Does it make sense?

[deviantintegral]

like we've done with security issues awaiting patches.
@deviantintegral is this in the Drainpipe's repo?

I don't think it is! @justafish do you think that makes sense to add?

Also, your thoughts on @beto-aveiga 's plan would be good too.

[justafish]

It's pending this issue: #112

I don't think it should be constrained to Tugboat - you should be able to provide any URL to test

[beto-aveiga]

I think this test should be just a script containing a drush command to check for no errors or warnings on the status report page.
We should add this script at /test/phpunit when running composer install if DRUPAL_TEST_TRAITS is TRUE... or similar, because we need a Drupal working site.

I don't have any LSM projects referencing DRUPAL_TEST_TRAITS, except for Lullabot, which is FALSE with a comment above: "Disable DTT tests until they are fixed."

[mrdavidburns]

see: drush core:requirements --severity=2

• Add to the ddev task build:dev command.

[beto-aveiga]

Just to let you know this has been solved here:
#684

And the PR is already approved.