v18.0.0 upgrade to redwood

overhangio · Jun 19, 2024 · 0ba4a22 · 0ba4a22
1 parent a6b0b68
commit 0ba4a22
Show file tree

Hide file tree

Showing 29 changed files with 77 additions and 83 deletions.
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -20,6 +20,45 @@ instructions, because git commits are used to generate release notes:
 
 <!-- scriv-insert-here -->
 
+<a id='changelog-18.0.0'></a>
+## v18.0.0 (2024-06-19)
+
+- 💥[Feature] Upgrade to Redwood (by @dawoudsheraz)
+- [Bugfix] Wrap Django5 warning imports in try-except block to avoid failures in django3 that's still in use in edx-platform's master branch (by @mariajgrimaldi).
+- 💥[Feature] Pull translations via `atlas` during Docker build. This breaks the `openedx-i18n` custom locale Tutor feature in favor of [OEP-58](https://docs.openedx.org/en/latest/developers/concepts/oep58.html) in favor of <https://github.com/openedx/openedx-translations>. (by @omarithawi)
+- 💥[Feature] The `openedx-assets` command is replaced with `npm run` subcommands. This will slightly reduce the build time for edx-platform assets and comprehensive themes. It will also open up the door for more significant build time reductions in the future. Here is a migration guide, where each command is to be run in the `lms` or `cms` container:
+
+  **Before**                               | **After**
+  -----------------------------------------|-------------------------------------------------------------------------------------
+  `openedx-assets build --env=prod ARGS`   | `npm run build -- ARGS`
+  `openedx-assets build --env=dev ARGS`    | `npm run build-dev -- ARGS`
+  `openedx-assets common --env=prod ARGS`  | `npm run compile-sass -- --skip-themes ARGS`
+  `openedx-assets common --env=dev ARGS`   | `npm run compile-sass-dev -- --skip-themes ARGS`
+  `openedx-assets webpack --env=prod ARGS` | `npm run webpack -- ARGS`
+  `openedx-assets webpack --env=dev ARGS`  | `npm run webpack-dev -- ARGS`
+  `openedx-assets npm`                     | `npm run postinstall` (`npm clean-install` runs this automatically)
+  `openedx-assets xmodule`                 | (no longer necessary)
+  `openedx-assets collect ARGS`            | `./manage.py lms collectstatic --noinput ARGS && ./manage.py cms collectstatic ARGS`
+  `openedx-assets watch-themes ARGS`       | `npm run watch-themes -- ARGS`
+
+For more details, see the [deprecation notice for paver](https://github.com/openedx/edx-platform/issues/34467)
+and the [static assets reference](https://github.com/openedx/edx-platform/tree/open-release/redwood.master/docs/references/static-assets.rst)
+in edx-platform.
+
+- 💥[Feature] Update MongoDB to v7.0.7 (by @dawoudsheraz) MongoDB is upgraded from version 4.4 to 7.0. Since there have been major releases since 4.4, the upgrade will need to go through them before running Mongo 7. MongoDB would need to follow 4.4 --> 5.0 --> 6.0 --> 7.0 upgrade path to work correctly. The container will keep on restarting with featureCompatibility error if the upgrade path is not followed. To upgrade mongo, run the following command based in the appropriate environment:
+
+    tutor <dev|local|k8s> upgrade --from=quince
+
+For k8s only, the above command will not perform the upgrade automatically. Instead, the command will output a series of commands that would need to be run manually to carry out the upgrade.
+
+- [Improvement] Upgrade Nodejs from 16.14.0 to 18.20.1 in edx-platform. (by @regisb)
+- [Improvement] Auto-detect bind mounts of openedx-learning for edx-platform (by @bradenmacdonald)
+- [Feature] Upgrade Open edX image to use Python 3.11 (by @dawoudsheraz)
+- [Bugfix] Remove CORS_ALLOW_HEADERS setting from the LMS/Studio config template. This setting, which holds site-agnostic application logic, is now consistently set to a reasonable value upstream by LMS and CMS config. Using the upstream values fixes a bug where course import in Studio using the new Course Authoring MFE was broken in Tutor deployments because it required additional headers to be allowed (content-range and content-disposition) (by @ormsbee)
+- [Improvement] Made Docker cache hits more frequent during the openedx image build via BuildKit's `COPY --link` feature (by @kdmccormick).
+- 💥[Improvement] Upgrade MySQL to 8.4.0. The upgrade should be automatic for most users. However, if you are running a third-party MySQL (i.e., RUN_MYSQL=false), you are expected to upgrade manually. Please refer to the third-party provider's documentation for detailed upgrade instructions. Ensuring that your MySQL version is up-to-date is crucial for maintaining compatibility and security. (by @rohansaeed)
+- 💥[Improvement] Ensure that the edx-platform repository git checkout is cached by Docker during image build. This means that the cache will automatically be cleared any time there is an upstream change. Thus, it is no longer necessary to run `tutor images build --no-cache` just to fetch the latest edx-platform changes. For this to work, any GitHub repository referenced by `EDX_PLATFORM_REPOSITORY` needs to end with ".git". Make sure that this is the case if you have modified the value of this setting in the past. (by @regisb)
+
 <a id='changelog-17.0.6'></a>
 ## v17.0.6 (2024-06-13)
 

diff --git a/changelog.d/20231212_140233_maria.grimaldi_fix_django4_import_errors.md b/changelog.d/20231212_140233_maria.grimaldi_fix_django4_import_errors.md
diff --git a/changelog.d/20231219_214829_i_atlas.md b/changelog.d/20231219_214829_i_atlas.md
diff --git a/changelog.d/20240124_080753_i_plugins_xblocks.md b/changelog.d/20240124_080753_i_plugins_xblocks.md
diff --git a/changelog.d/20240318_154804_kyle_assets_build.md b/changelog.d/20240318_154804_kyle_assets_build.md
diff --git a/changelog.d/20240329_164354_dawoud.sheraz_mongo_update.md b/changelog.d/20240329_164354_dawoud.sheraz_mongo_update.md
diff --git a/changelog.d/20240410_102248_regis_node18.md b/changelog.d/20240410_102248_regis_node18.md
diff --git a/changelog.d/20240425_105236_braden_bind_mount_docs.md b/changelog.d/20240425_105236_braden_bind_mount_docs.md
diff --git a/changelog.d/20240502_200434_dawoud.sheraz_py311.md b/changelog.d/20240502_200434_dawoud.sheraz_py311.md
diff --git a/changelog.d/20240508_111720_dave_fix_cors_headers.md b/changelog.d/20240508_111720_dave_fix_cors_headers.md
diff --git a/changelog.d/20240531_094930_kyle_assets_link.md b/changelog.d/20240531_094930_kyle_assets_link.md
diff --git a/changelog.d/20240531_132815_rohan.saeed_supply_mysql8_4_0.md b/changelog.d/20240531_132815_rohan.saeed_supply_mysql8_4_0.md
diff --git a/changelog.d/20240607_111921_regis_edx_platform_code_cache.md b/changelog.d/20240607_111921_regis_edx_platform_code_cache.md
diff --git a/docs/configuration.rst b/docs/configuration.rst
@@ -132,7 +132,7 @@ Open edX customisation
 
 This defines the git repository from which you install Open edX platform code. If you run an Open edX fork with custom patches, set this to your own git repository. You may also override this configuration parameter at build time, by providing a ``--build-arg`` option.
 
-- ``OPENEDX_COMMON_VERSION`` (default: ``"open-release/quince.1"``, or ``master`` in :ref:`nightly <nightly>`)
+- ``OPENEDX_COMMON_VERSION`` (default: ``"open-release/redwood.1"``, or ``master`` in :ref:`nightly <nightly>`)
 
 This defines the default version that will be pulled from all Open edX git repositories.
 
@@ -378,9 +378,9 @@ Note that your edx-platform version must be a fork of the latest release **tag**
 
 If you don't create your fork from this tag, you *will* have important compatibility issues with other services. In particular:
 
-- Do not try to run a fork from an older (pre-Quince) version of edx-platform: this will simply not work.
+- Do not try to run a fork from an older (pre-Redwood) version of edx-platform: this will simply not work.
 - Do not try to run a fork from the edx-platform master branch: there is a 99% probability that it will fail.
-- Do not try to run a fork from the open-release/quince.master branch: Tutor will attempt to apply security and bug fix patches that might already be included in the open-release/quince.master but which were not yet applied to the latest release tag. Patch application will thus fail if you base your fork from the open-release/quince.master branch.
+- Do not try to run a fork from the open-release/redwood.master branch: Tutor will attempt to apply security and bug fix patches that might already be included in the open-release/redwood.master but which were not yet applied to the latest release tag. Patch application will thus fail if you base your fork from the open-release/redwood.master branch.
 
 .. _i18n:
 

diff --git a/docs/dev.rst b/docs/dev.rst
@@ -113,7 +113,7 @@ The ``openedx-dev`` Docker image is based on the same ``openedx`` image used by
 
 - The user that runs inside the container has the same UID as the user on the host, to avoid permission problems inside mounted volumes (and in particular in the edx-platform repository).
 - Additional Python and system requirements are installed for convenient debugging: `ipython <https://ipython.org/>`__, `ipdb <https://pypi.org/project/ipdb/>`__, vim, telnet.
-- The edx-platform `development requirements <https://github.com/openedx/edx-platform/blob/open-release/quince.master/requirements/edx/development.in>`__ are installed.
+- The edx-platform `development requirements <https://github.com/openedx/edx-platform/blob/open-release/redwood.master/requirements/edx/development.in>`__ are installed.
 
 
 If you are using a custom ``openedx`` image, then you will need to rebuild ``openedx-dev`` every time you modify ``openedx``. To so, run::

diff --git a/docs/install.rst b/docs/install.rst
@@ -123,11 +123,11 @@ Major Open edX releases are published twice a year, in June and December, by the
 4. Test the new release in a sandboxed environment.
 5. If you are running edx-platform, or some other repository from a custom branch, then you should rebase (and test) your changes on top of the latest release tag (see :ref:`edx_platform_fork`).
 
-The process for upgrading from one major release to the next works similarly to any other upgrade, with the ``launch`` command (see above). The single difference is that if the ``launch`` command detects that your tutor environment was generated with an older release, it will perform a few release-specific upgrade steps. These extra upgrade steps will be performed just once. But they will be ignored if you updated your local environment (for instance: with ``tutor config save``) before running ``launch``. This situation typically occurs if you need to re-build some Docker images (see above). In such a case, you should make use of the ``upgrade`` command. For instance, to upgrade a local installation from Palm to Quince and rebuild some Docker images, run::
+The process for upgrading from one major release to the next works similarly to any other upgrade, with the ``launch`` command (see above). The single difference is that if the ``launch`` command detects that your tutor environment was generated with an older release, it will perform a few release-specific upgrade steps. These extra upgrade steps will be performed just once. But they will be ignored if you updated your local environment (for instance: with ``tutor config save``) before running ``launch``. This situation typically occurs if you need to re-build some Docker images (see above). In such a case, you should make use of the ``upgrade`` command. For instance, to upgrade a local installation from Quince to Redwood and rebuild some Docker images, run::
 
     tutor config save
     tutor images build all # list the images that should be rebuilt here
-    tutor local upgrade --from=palm
+    tutor local upgrade --from=quince
     tutor local launch
 
 .. _autocomplete:

diff --git a/docs/quickstart.rst b/docs/quickstart.rst
@@ -22,7 +22,7 @@ Yes :) This is what happens when you run ``tutor local launch``:
 2. Configuration files are generated from templates.
 3. Docker images are downloaded.
 4. Docker containers are provisioned.
-5. A full, production-ready Open edX platform (`Quince <https://edx.readthedocs.io/projects/edx-installing-configuring-and-running/en/open-release-quince.master/platform_releases/quince.html>`__ release) is run with docker-compose.
+5. A full, production-ready Open edX platform (`Redwood <https://edx.readthedocs.io/projects/edx-installing-configuring-and-running/en/open-release-redwood.master/platform_releases/redwood.html>`__ release) is run with docker-compose.
 
 The whole procedure should require less than 10 minutes, on a server with good bandwidth. Note that your host environment will not be affected in any way, since everything runs inside docker containers. Root access is not even necessary.
 

diff --git a/docs/reference/indexes.rst b/docs/reference/indexes.rst
@@ -7,10 +7,10 @@ Plugin indexes are a great way to have your plugins discovered by other users. P
 Index file paths
 ================
 
-A plugin index is a yaml-formatted file. It can be stored on the web or on your computer. In both cases, the index file location must end with "<current release name>/plugins.yml". For instance, the following are valid index locations if you run the Open edX "Quince" release:
+A plugin index is a yaml-formatted file. It can be stored on the web or on your computer. In both cases, the index file location must end with "<current release name>/plugins.yml". For instance, the following are valid index locations if you run the Open edX "Redwood" release:
 
-- https://overhang.io/tutor/main/quince/plugins.yml
-- ``/path/to/your/local/index/quince/plugins.yml``
+- https://overhang.io/tutor/main/redwood/plugins.yml
+- ``/path/to/your/local/index/redwood/plugins.yml``
 
 To add either indexes, run the ``tutor plugins index add`` command without the suffix. For instance::
 
@@ -106,9 +106,9 @@ Manage plugins in development
 Plugin developers and maintainers often want to install local versions of their plugins. They usually achieve this with ``pip install -e /path/to/tutor-plugin``. We can improve that workflow by creating an index for local plugins::
 
     # Create the plugin index directory
-    mkdir -p ~/localindex/quince/
+    mkdir -p ~/localindex/redwood/
     # Edit the index
-    vim ~/localindex/quince/plugins.yml
+    vim ~/localindex/redwood/plugins.yml
 
 Add the following to the index::
 

diff --git a/docs/tutorials/edx-platform.rst b/docs/tutorials/edx-platform.rst
@@ -69,7 +69,7 @@ Quite often, developers don't want to work on edx-platform directly, but on a de
     cd /my/workspace/edx-ora2
     git clone https://github.com/openedx/edx-ora2 .
 
-Then, check out the right version of the package. This is the version that is indicated in the `edx-platform/requirements/edx/base.txt <https://github.com/openedx/edx-platform/blob/open-release/quince.master/requirements/edx/base.txt>`__. Be careful that the version that is currently in use in your version of edx-platform is **not necessarily the head of the master branch**::
+Then, check out the right version of the package. This is the version that is indicated in the `edx-platform/requirements/edx/base.txt <https://github.com/openedx/edx-platform/blob/open-release/redwood.master/requirements/edx/base.txt>`__. Be careful that the version that is currently in use in your version of edx-platform is **not necessarily the head of the master branch**::
 
     git checkout <my-version-tag-or-branch>
 

diff --git a/requirements/plugins.txt b/requirements/plugins.txt
@@ -1,14 +1,14 @@
-# change version ranges when upgrading from quince
-tutor-android>=17.0.0,<18.0.0
-tutor-cairn>=17.0.0,<18.0.0
-tutor-credentials>=17.0.0,<18.0.0
-tutor-discovery>=17.0.0,<18.0.0
-tutor-ecommerce>=17.0.0,<18.0.0
-tutor-forum>=17.0.0,<18.0.0
-tutor-indigo>=17.0.0,<18.0.0
-tutor-jupyter>=17.0.0,<18.0.0
-tutor-mfe>=17.0.0,<18.0.0
-tutor-minio>=17.0.0,<18.0.0
-tutor-notes>=17.0.0,<18.0.0
-tutor-webui>=17.0.0,<18.0.0
-tutor-xqueue>=17.0.0,<18.0.0
+# change version ranges when upgrading from redwood
+tutor-android>=18.0.0,<19.0.0
+tutor-cairn>=18.0.0,<19.0.0
+tutor-credentials>=18.0.0,<19.0.0
+tutor-discovery>=18.0.0,<19.0.0
+tutor-ecommerce>=18.0.0,<19.0.0
+tutor-forum>=18.0.0,<19.0.0
+tutor-indigo>=18.0.0,<19.0.0
+tutor-jupyter>=18.0.0,<19.0.0
+tutor-mfe>=18.0.0,<19.0.0
+tutor-minio>=18.0.0,<19.0.0
+tutor-notes>=18.0.0,<19.0.0
+tutor-webui>=18.0.0,<19.0.0
+tutor-xqueue>=18.0.0,<19.0.0
diff --git a/tests/test_env.py b/tests/test_env.py
@@ -260,7 +260,7 @@ def test_current_version_in_latest_env(self) -> None:
             ) as f:
                 f.write(__version__)
             self.assertEqual(__version__, env.current_version(root))
-            self.assertEqual("quince", env.get_env_release(root))
+            self.assertEqual("redwood", env.get_env_release(root))
             self.assertIsNone(env.should_upgrade_from_release(root))
             self.assertTrue(env.is_up_to_date(root))