Skip to content

Sumac Sandbox & Release Preparation #1121

New issue
New issue
Closed
Closed
Sumac Sandbox & Release Preparation#1121
@DawoudSheraz

Description

@DawoudSheraz
DawoudSheraz
opened on Sep 13, 2024

This issue is for tracking the items to prepare https://github.com/overhangio/openedx-release-demo for Sumac cutoff.

Sumac cutoff is expected to take place on October 23, 2024. Once the branches are out on upstream, the community will be looking forward to sandbox provided by Edly. tutor and its plugins will require sumac branches with appropriate changes for the sandbox to complete. The necessary information is already present on https://edlyio.atlassian.net/wiki/spaces/openedx/pages/3013148726/Building+Open+edX+major+releases. A note: once the branches are created, any changes to nightly would need to be manually added to the sumac branch. Therefore, a rebase on nightly whenever nightly changes would be required to ensure the sumac branch is always up-to-date

This issue is meant for tracking the statuses of various repositories needed for sandbox. It will act as a todo list to ensure that tutor and its plugins have sumac branches created from nightly before the cutoff date (even though there will be potential failures on CI against it) and have a PR against master.
For sanity checks, make sure to run image build and init task on local tutor <local/dev> do init --limit=pluginnname.

The sandbox script expects the branches to be available on the main repository, not the fork. If you are assigned a repository but you cannot push to it directly, please get in touch with @DawoudSheraz or the maintainer of the repository with patch file so that they can create the PR in the appropriate repository with your provided changes

Tutor & Plugins Todo List

Available on launch

Available within a week

Not needed for sandbox

Sandbox Repo Todo List

Context

Every six months, Tutor maintainers sync up with the Build/Test/Release working group to create the next version, both of Open edX and Tutor.

In the scenario below, we are upgrading Open edX from fictional “Delta” to “Epsilon”. Tutor will upgrade from v4 to v5 (“d”=4, “e”=5).

(these instructions are pulled and adapted from this old discussion topic)

Create release branches

In Tutor core and all plugins, we must create “epsilon” branches off of the nightly branches. For each repo, this looks like the following:

git checkout nightly

git pull

git checkout -b epsilon

Push the created “epsilon” branch to the upstream repo: git push

Upgrade Tutor core and plugins

  • Modify about.py:
    • bump the version number to 5.0.0.
  • in Tutor core, set the version_suffix to an empty string.
  • In plugins’ setup.py, bump the version of the “tutor” package that the plugin depends on:
install_requires=["tutor>=5.0.0,<6.0.0"],
extras_require={"dev": ["tutor[dev]>=5.0.0,<6.0.0"]},
  • Create a changelog entry with make changelog-entry: "💥[Feature] Upgrade to Epsilon. (by @YourGithubUsername)"
  • Replace all instances of “[dD]elta” that make sense (i.e: not in the CHANGELOG.md!)
  • Go through the Dockerfile templates and manually upgrade all the 3rd-party requirements that you can find (dockerize, ipdb, etc.). Sometimes it’s not desirable to upgrade some pieces of software: for instance node and python are expected to run a specific version. Those required version numbers are specified in the edx/configuration 5 repo. (look for SERVICENAME_VERSION variables)
  • Make sure that the plugin images (if any) are built correctly: tutor images build all.
  • Make sure that the plugin can be correctly initialized: tutor local do init --limit=pluginnname.
  • If you need to make some changes to the docker-compose*.yml files and patches, make sure to backport these changes to the k8s-* patches, for compatibility with Kubernetes.
  • Make sure that the plugins work correctly by doing some basic usage testing. Pay close attention to any log (warning or error) that come out of the plugin containers as well as the lms container.
  • git commit -a -m v5.0.0
  • Push the created “epsilon” branch to the upstream repo: git push

The release branches should be updated regularly to take into account the latest changes from the nightly branch. During the release process, it is frequent that changes are pushed to the master and nightly branches, and the latest “espilon” branch must have those changes as well. Be prepared to push --force the “espsilon” branches frequently.

⚠️ Plugin tests will fail in the release branches, because the plugins can’t find tutor>=5.0.0 on pypi. To resolve that, we should update the test scripts to install tutor from source (pip install -e --config-settings editable_mode=compat https://github.com/overhangio/tutor@epsilon#egg=tutor). But it’s inconvenient to do that for each and every plugin. So maybe we should consider migrating to a centralized “tutor-test-plugin” GitHub action. This action would be versioned according to the Tutor major version (@5).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Tutor project management

    Status

    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions