Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
For visibility and efficiency, error logs need to be exposed for both system administrators and for end users to more effectively debug.
Proposed solution:
1. Ensure PHP.ini spawns with error reporting and display errors
2. Update the vhost settings to write errors into the docroot (e.g. errors.txt or errors.log if its served)
3. Evaluate the output of Drush installation to capture (at least) provisioning errors (e.g. provision.txt/provision.log)
This is short term and we can evaluate better solutions moving forward.
Comment | File | Size | Author |
---|---|---|---|
#27 | 2946732-show_logs-25.patch | 9.66 KB | nerdstein |
#25 | 2946732-show_logs-24.patch | 9.3 KB | nerdstein |
#12 | 2946732-show_logs-12.patch | 5.51 KB | nerdstein |
#11 | 2946732-show_logs-11.patch | 5.54 KB | nerdstein |
#10 | 2946732-show_logs-10.patch | 4.13 KB | nerdstein |
Comments
Comment #2
nerdsteinComment #3
nerdsteinBumping this up since we have launched the new TugboatQA backend. The primary need is around the installation and exposing visibility during the install, should things fail. This will help give people direct feedback on why a failure occurs when an instance is created.
SimplyTest is already writing the installation log output to a file after the install finishes. I think it would be much nicer to get output on the fly.
Something like this may make it possible via the API: https://api.tugboat.qa/api/previews/log/
Here is a very rough idea of how this can work.
1. A callback should be created that invokes the backend API call (this has the Tugboat config/key). This should retrieve the preview log and return an updated log.
2. We need to get the log periodically (10 seconds maybe?) through a front-end poling mechanism. This poling mechanism should only run during the install stop poling in all of the following conditions: a. an instance fails, b. an instance is successful.
3. A block should be created and be able to be placed on the progress page.
Comment #4
webchickBig +1 to this feature. Over at #3083188: "The requested submission failed. 113%" you can see repeated reports of the dread "The requested submission failed. 113%" error. Upon further digging (by Adam, since us mere peon users cannot see this information atm), it turns out this is nearly always caused because the project in question is doing something funky, and could be resolved by the end users themselves. But not having that information, it leads us peon end users to the conclusion that simplytest.me (and/or Tugboat QA) itself is overly buggy and only works part of the time.
Comment #5
nerdsteinThis is a WIP but I want to push this up to see if it works.
Comment #6
nerdsteinAnother test
Comment #7
nerdsteinAnother WIP
Comment #8
nerdsteinBug...
Comment #9
nerdsteinMore WIP for testing
Comment #10
nerdsteinComment #11
nerdsteinChanged rendering approach - WIP for testing
Comment #12
nerdsteinComment #13
nerdsteinComment #14
nerdsteinThis last patch is trying to process too much data and timing out. This was bundled with the progress updater AJAX to make use of that same refreshing code. It likely needs decoupled from it.
Comment #15
nerdsteinThis is getting a rendered log now but needs a ton of styling cleanup. This is a first attempt.
Comment #16
nerdsteinThat was a bad patch, reuploading
Comment #17
nerdsteinComment #18
nerdsteinComment #19
nerdsteinThis one tests well locally, pushing for testing
Comment #20
nerdsteinForgot to add the new CSS file
Comment #21
nerdsteinstderr is not just for errors. It would be nice to highlight errors somehow. But, this cleans things up... one more time...
Comment #22
nerdsteinAvoiding previously used drupal classes....
Comment #23
nerdsteinThe patch is up on https://bergste.in
Feedback welcomed
Comment #24
nerdsteinThis should address the red highlighting of errors
Comment #25
nerdsteinComment #26
nerdsteinThe patch got the coloring of the log entries I wanted in place. However, after a failure, it continues to refresh indefinitely. It should stop and leave the log intact.
Comment #27
nerdsteinComment #28
nerdsteinThat looks good
Comment #30
nerdstein