...
Access to application logs
Status of sandbox build
At a minimum: Always-fail-loudly. That is, “nothing” should never happen, there should always be a comment when the build fails for any reason.
Note: We used to have comments for this, but turned them off because they were too noisy. Would there be a less noisy way ot notifying?
Idea: Use the GitHub checks system rather than bot comments
Idea: Configurable notification levels
Idea: One comment updated with status over time
More examples in the docs on how to do complex configuration, including
MFE config
Waffle flags
Custom MFEs
Branches of Tutor plugins
Site configuration (broken link in tutor-contrib-grove)
____________________________
SSH access to the sandboxes
Deploying from a tag or branch
____________________________
Automatically import the demo course, with configuration it to be from a branch
Ability to fully destroy and recreate the sandbox without using the remove-label-wait-and-put-it-back workaround described above.
Ability to force a redeploy without pushing a commit. This can be desirable when a change is pushed to a dependency other than the PR itself (e.g. a Tutor branch).
Dashboard of existing sandboxes.
Note: you can kinda get at this by filtering on the create-sandbox label
...