Page Comparison

...

• Access to application logs

• 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

• Notification that sandbox is building for a given PRStatus 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

  Always-fail-loudly. That is, “nothing” should never happen, there should always be a comment when the build fails for any reason.

  • 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

• ____________________________

• 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

...