rig project doctor

[grayside]

Should we have a rig project doctor?

I've gone back and forth on this a bit: Should it be a generated script? Should it be in rig? A separate tool? Extensible? Runnable from Jenkins? Lots of questions.

With this functionality, we may be able to automate checks for a lot more of the problems projects run into and fasttrack diagnoses.

Here's the specification of what I had in mind:

doctor:
  conditions:
    -
      name: Valid Project Configuration
      diagnosis: Your docker-compose files do not provide a valid configuration.
      prescription: Evaluate the errors and revise the configuration files as needed.
      # If a check fails on a fatal severity issue, stop the process.
      severity: error
      check:
        - validate-docker-compose.sh
        - docker-compose -f build.yml run --rm composer validate
    -
      name: Scaffolded Files Exist
      diagnosis: Some of the generated files for your project have gone missing. This can lead to unpredictable results.
      prescription: Replace missing files from git history or a rerun of the generator. If any file is not needed, please delete from this check.
     severity: warning
     # Checks should be run sequentially and the whole step failed if any one fails.
     check:
       - ls src > /dev/null
       - ls package.json > /dev/null
  -
    name: Database Failure
    diagnosis: The project database could not start up because of broken configuration or logfiles the database interprets as a lockout status.
    prescription: Delete the indicated file(s).
    severity: error
    check:
      - docker-compose exec db bash -c "ls /var/lib/mysql/tc.log"

Built-in Checks

Unison Sync Crash

• Diagnosis: Your unison sync crashed and will not work without further action.
• Prescription: Stop your project containers, run docker container rm -f projectname-sync and docker volume rm -f projectname-sync
• Severity: Fatal

Containers Down

• Diagnosis: No containers associated with the projectname are currently operating.
• Prescription: Start your project containers before relying on their services.
• Severity: Warning

[grayside]

I 'reopened' the idea of doing this when I got most of the way through a change to rig to allow rig project sync:start to be run with a flag to first wipe the existing sync container, before realizing that was black magic for the team to learn, and something to instruct them on the directly docker way to handle the problem would be better for learning purposes.