Page Comparison

...

• The admin username is openedx and the password is the same. If you want to secure your sandbox’s data against public access, then change the admin password. You should also be able to create unprivileged user accounts as necessary.

• The sandbox will redeploy every ~15 minutes if either of the following conditions are met:

  • The PR’s latest commit hash has changed

  • The PR’s Settings or Tutor Requirements sections have changed

• The sandbox will be destroyed after ~15 minutes if either of the following conditions are met:

  • The create-sandbox label has been removed

  • The PR is merged or closed

• When the sandbox redeploys, its database is preserved. To fully destroy and recreate with a fresh db, you will need a workaround:

  • Remove the create-sandbox label

  • Wait ~15 minutes

  • Check that the sandbox has been destroyed by going to the LMS. You should see a message like “This site is being provisioned”.

  • Put the create-sandbox label back

• If your edx-platform branch (or the configured EDX_PLATFORM_VERSION) has migration changes that are incompatible with migrations that have already been applied to the sandbox’s db, then you will need to fully destroy and recreate with a fresh db (see above). A couple ways this can happen: force-pushing a modified migration; switching the base branch from master to <release>.master or vice-versa.

• Idle sandboxes will be destroyed after weeks of inactivity. You can bring them back to life by pushing a new commit or rebasing your PR.

• We have a usage budget for about 30 running instances. OpenCraft will let us know if we’re bumping up against that.

• PRs to master/main will use Tutor Nightly. PRs to named release branches will use the latest patch release of the corresponding Tutor version (e.g., Quince → tutor>=17,<18). The Tutor version can be overridden using the Tutor Requirements section, as explained in the docs.

...

• 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

• 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

...