Page Comparison

...

• More access

  • to application logs (Need to have)

  • to the box itself via ssh (Nice to have)

• Better status communication

  • Always fail loudly. That is: when you request a sandbox, something should happen. Either you should get a sandbox, or get a failure notification. No ghosting! 👻 This is true about 80% of the time now, but that 20% is enough to shake our confidence in the system as a whole.

    • Note: We used to have comments for this, but turned them off because they were too noisy. Would there be a less noisy way of notifying?

    • Idea: Use the GitHub checks system rather than bot comments

    • Idea: Configurable notification levels

    • Idea: Use one comment, and amend it to the update the status over time

  • Dashboard of existing sandboxes.

    • Note: you can kinda get at this by filtering on the create-sandbox label

• More examples in the docs on how to do complex configuration, including

  • MFE config

  • Waffle flags

  • Custom MFEs

  • Using branches/tags of Tutor plugins

  • Site configuration (broken link in tutor-contrib-grove)

• More controls

  • 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).

• Auto-provisioned data

  • openedx-demo-course, with configuration fork/branch

  • openedx-test-course, with configuration fork/branch

• Auto-deploy from a tag or branch without having to have a PR

  • master

  • release branches

  • (This was an old action item. It seems unnecessary now that we have Adolfo’s openedx.io sandboxes, unless he wants to stop having to manually manage those)

...