Release instructions updates

source/Reviewers/curaterelease.rst

@@ -65,42 +65,49 @@ sources in the dependencies.yaml file are as they should be. This section is
 relevant for all repositories with a stable and main branch setup.
 
 The release process will be completed by 2 people with commit privilege to the
-relevant repository, at least one of whom must be an ``admin``. One will have
-developed the release branch and the other will review it (**developer** and
-**reviewer** below).
+relevant repository. One will have developed the release branch and the other
+will review it (**developer** and **reviewer** below). It's also worth making
+sure both people have signed the relevant CONTRIBUTORS file - do this in a
+separate PR first if not.
+
+* Before starting, an ``admin`` on the repository will need to update some
+  rulesets:
+
+  * ``prevent_updates``
+
+    * Set ``stable`` as an excluded branch
+
+  * ``main``
+
+    * Disable the ``Require Linear History`` setting
+    * Set the only allowed merge method as ``merge`` (remove ``squash``)
 
 * The **developer** should open a PR directly in the MetOffice repository by
   going to the Pull Requests tab and selecting the New Pull Request button.
   Target the ``stable`` branch.
 
-    .. image:: images/gh_screenshots/main_stable_light.png
-       :class: only-light border
+  .. image:: images/gh_screenshots/main_stable_light.png
+    :class: only-light border
 
-    .. image:: images/gh_screenshots/main_stable_dark.png
-        :class: only-dark border
+  .. image:: images/gh_screenshots/main_stable_dark.png
+    :class: only-dark border
 
-* An admin will need to enable updates to the ``stable`` branch by adding it as
-  an exception to the target branches in the ``prevent updates`` ruleset.
 * The **reviewer** will then review and commit the PR. When committing the
   branch, ensure that the merge method is ``merge``. This should be the default
   for the ``stable`` branch as we want to keep the history of ``main`` in the
   ``stable`` branch.
+
+  If there have been any changes to the CONTRIBUTORS file during the release,
+  the CLA Check action will fail in this PR. It is not a required status check
+  when merging to ``stable`` so it can be safely ignored.
 * The **developer** will then create another new PR as above, to merge the
   ``stable`` branch into ``main``.
 
-    .. image:: images/gh_screenshots/stable_main_light.png
-       :class: only-light border
-
-    .. image:: images/gh_screenshots/stable_main_dark.png
-        :class: only-dark border
+  .. image:: images/gh_screenshots/stable_main_light.png
+    :class: only-light border
 
-* At this point an admin will need to modify the branch protection rules for the
-  ``main`` branch, so that the commit can be performed with a normal merge. This
-  keeps ``main`` and ``stable`` with an identical history.
-
-  * Navigate to the ``main`` ruleset.
-  * Disable ``Require linear history``.
-  * Set ``merge`` as an allowed merge strategy and disable ``squash``.
+  .. image:: images/gh_screenshots/stable_main_dark.png
+    :class: only-dark border
 
 * The **reviewer** can now ``merge`` the second PR.
 * The admin **must** now revert the 2 settings above in ``main`` and remove the
@@ -113,35 +120,40 @@ Hotfix Release
 This section describes the process of applying a hotfix to the most recent
 release. This section is relevant for all repositories with a stable and main
 branch setup. The hotfix process will be completed by 2 people with commit
-privilege to the relevant repository, at least one of whom must be an ``admin``.
-One will have developed the hotfix branch and the other will review it
-(**developer** and **reviewer** below).
+privilege to the relevant repository. One will have developed the hotfix branch
+and the other will review it (**developer** and **reviewer** below).
 
-* An admin will need to enable updates to the ``stable`` branch by adding it as
-  an exception to the target branches in the ``prevent updates`` ruleset. They
-  should also enable ``squash`` as a merge option in the ``stable`` ruleset.
-* The **developer** will make the hotfix change, making sure the branch has been
-  created from ``stable``. Open a PR for this change targetting ``stable`` and
-  get it reviewed and committed. The **reviewer** should squash this change into
-  ``stable``.
-* The admin should now update the ``main`` ruleset:
+* Before starting, an ``admin`` on the repository will need to update some
+  rulesets:
+
+  * ``prevent_updates``
+
+    * Set ``stable`` as an excluded branch
+
+  * ``stable``
+
+    * Set the only allowed merge method as ``squash`` (remove ``main``)
 
-  * Disable ``Require linear history``.
-  * Set ``merge`` as an allowed merge strategy and disable ``squash``.
-  * Uncheck the ``Require branches to be up to date`` box.
+  * ``main``
 
+    * Disable the ``Require Linear History`` setting
+    * Set the only allowed merge method as ``merge`` (remove ``squash``)
+
+* The **developer** will make the hotfix change, making sure the branch has been
+  created from ``stable``. Open a PR for this change targetting ``stable`` and
+  get it reviewed and committed. The **reviewer** should ``squash`` this change
+  into ``stable``.
 * The **developer** will then create another new PR, to merge the
   ``stable`` branch into ``main``.
 
-    .. image:: images/gh_screenshots/stable_main_light.png
-       :class: only-light border
+  .. image:: images/gh_screenshots/stable_main_light.png
+    :class: only-light border
 
-    .. image:: images/gh_screenshots/stable_main_dark.png
-        :class: only-dark border
+  .. image:: images/gh_screenshots/stable_main_dark.png
+    :class: only-dark border
 
 * The **reviewer** can now ``merge`` the second PR.
-* The admin **must** now revert the 3 settings above in ``main`` and remove the
-  exception for ``stable`` in the ``prevent updates`` ruleset from earlier.
+* The admin **must** now revert the ruleset changes made above.
 * :ref:`Tag <tagging>` the hotfix.
 
 .. _tagging:

source/Reviewers/releases/lfric_apps_release.rst

@@ -75,6 +75,11 @@ LFRic Release
     * Update ``ref`` for all other repositories to be the Simulation Systems tag
       ``YYYY.MM.1``, checking that the dependencies look as they should.
 
+* If required, update the lfric modules for the Azspice and EX1A in
+  ``rose-stem/site/meto/common/suite_config_*.cylc`` in both Apps and Core.
+  These may already have been updated as part of a software stack upgrade, but
+  if not, increase the version number here. If the modules don't exist then ask
+  the spack admins to create copies of the previous versions.
 
 * Commit your changes to both Apps and Core branches.
 
@@ -85,7 +90,7 @@ LFRic Release
 * Once testing is complete, update LFRic Core in ``dependencies.yaml``
 
   * ``source`` should be the MetOffice ssh url
-  * ``ref`` should be ``coreX.Y``
+  * ``ref`` should be the SimSys Tag ``YYYY.MM.X``
 
 * Open a PR for each and with a reviewer, follow the
   :ref:`review process <github-releases>`

source/Reviewers/releases/milestones.rst

@@ -12,33 +12,41 @@ Milestones and Projects
 #. Tidy up all pull requests and issues for the completed milestone in the
    Simulation Systems Review and Issues Trackers.
 
-    .. code-block:: shell
+   .. code-block:: shell
 
-       python SimSys_Scripts/gh_review_project/finish_milestone.py --milestone="<milestone title>"
+      python SimSys_Scripts/gh_review_project/finish_milestone.py --milestone="<milestone title>"
 
-       with optional argument ``--dry`` to dry run the changes.
+      with optional argument ``--dry`` to dry run the changes.
 
-    The script will prompt for you to continue after checking all PRs and issues
-    are in a suitable state. If it flags items that need correcting then go to
-    `Simulation Systems Review Tracker`_ and
-    `Simulation Systems Issue Tracker`_ to manually sort them.
+   The script will prompt for you to continue after checking all PRs and issues
+   are in a suitable state. If it flags items that need correcting then go to
+   `Simulation Systems Review Tracker`_ and
+   `Simulation Systems Issue Tracker`_ to manually sort them.
+
+   .. note::
+
+      The github review project page can take a
+      `long time <https://github.com/orgs/community/discussions/186349>`_ (> 30
+      minutes) to update after running this script. Check that a given PR has
+      been archived on the PR page, then feel free to carry on if this is the
+      case.
 
 #. As prompted by the above script, close the current milestone using:
 
-    .. code-block:: shell
+   .. code-block:: shell
 
-        ./SimSys_Scripts/sbin/gh_manage_milestones -t <title of milestone> -m close
+      ./SimSys_Scripts/sbin/gh_manage_milestones -t <title of milestone> -m close
 
 #. Open the next new milestone so that there are the same number of open milestones:
 
-    .. code-block:: shell
+   .. code-block:: shell
 
-        ./SimSyS_Scripts/sbin/gh_manage_milestones -t <title> -d YYYY-MM-DDTHH:MM:SSZ -p <description>
+      ./SimSyS_Scripts/sbin/gh_manage_milestones -t <title> -d YYYY-MM-DDTHH:MM:SSZ -p <description>
 
-    * the title is ``Spring YYYY``, ``Summer YYYY`` or ``Autumn YYYY``
-    * the date is the first Wednesday in March, July or November
-    * the description is ``Code Review deadline is <date> (SciTech review to be completed by this date)``
-      selecting a Friday at the end of January/May/September for the deadline.
+   * the title is ``Spring YYYY``, ``Summer YYYY`` or ``Autumn YYYY``
+   * the date is the first Wednesday in March, July or November
+   * the description is ``Code Review deadline is <date> (SciTech review to be completed by this date)``
+     selecting a Friday at the end of January/May/September for the deadline.
 
 .. _Simulation Systems Review Tracker: https://github.com/orgs/MetOffice/projects/376
 .. _Simulation Systems Issue Tracker: https://github.com/orgs/MetOffice/projects/418

source/Reviewers/releases/other_repos.rst

@@ -9,6 +9,11 @@
 Other Repositories
 ==================
 
+.. note::
+
+  "Simulations Systems release tag" below refers to a tag of ``YYYY.MM.X``
+  format.
+
 1. Apply a Simulation Systems release tag to SimSys_Scripts.
 
 2. Create a UKCA branch updating the SimSys_Scripts tag in the dependencies.yaml
@@ -17,19 +22,23 @@ Other Repositories
 3. Follow the process of updating :ref:`Stable and Main<github-releases>` for
    these repositories:
 
-  * ukca
-  * casim
-  * socrates
-  * moci
+   * ukca
+   * casim
+   * socrates
+   * moci
+   * mule (if not already done as part of a release)
+   * shumlib (if not already done as part of a release)
 
 4. Apply a Simulation Systems release tag to each of:
 
-  * ukca
-  * casim
-  * socrates
-  * moci
-  * um_aux
-  * socrates-spectral
+   * ukca
+   * casim
+   * socrates
+   * moci
+   * um_aux
+   * socrates-spectral
+   * mule (if not already done as part of a release)
+   * shumlib (if not already done as part of a release)
 
 5. Send an email to all repository owners to let them know that the repository has
 been tagged.

source/Reviewers/releases/standard_suites.rst

@@ -32,9 +32,12 @@ Then upgrade each suite by doing the following,
 * Move into the suite and edit the ``rose-suite.conf`` file,
 
   * If it has a ``VN`` setting, update it to the new version.
-  * If it has a ``prebuild`` path, update that now. If there are prebuilds,
-    check the ``flow.cylc`` for any prebuild path overrides. These exist
-    particularly on the EXs.
+
+* Edit the ``dependencies.yaml`` file so that each ``ref`` points at the
+  SimSys release tag.
+
+  * Take care with shumlib as this may have a different tag associated with it's
+    most recent release.
 
 * Validate the existing apps by running,
 
@@ -100,6 +103,8 @@ For each suite, do the following:
     cd ~/roses/u-dn704
 
 * In ``rose-suite.conf`` update the version number
+* Edit the ``dependencies.yaml`` file so that each ``ref`` points at the
+  SimSys release tag.
 * Upgrade the metadata for the mesh and lfric_atm apps
 
   .. code-block::

source/Reviewers/releases/um_main_release.rst

@@ -17,8 +17,7 @@ repositories, and that the ``main`` branches in each are up to date with the
 upstream repository.
 
 In a clone of these forks, :ref:`create a branch <create_branch>` using the
-``main`` branch as the parent. In the UM branch, update the ``um_meta`` entry in
-the ``dependencies.yaml`` file to point at your metadata branch.
+``main`` branch as the parent.
 
 .. important::
 
@@ -29,18 +28,13 @@ the ``dependencies.yaml`` file to point at your metadata branch.
 Dependencies
 ------------
 
-For each of these repositories, modify the ``ref`` in the UM
-``dependencies.yaml`` file, to point at the new Simulation Systems release tag.
+For all repositories (other than the exceptions below) in the
+``dependencies.yaml`` file, modify the ``ref`` to point at the new Simulation
+Systems release tag.
 
-* JULES
-* SOCRATES
-* UKCA
-* CASIM
-* MOCI
-
-Also update the ``ref`` for Mule and SHUMLIB to point to their latest releases.
-
-Commit this change to the branch.
+* ``mule`` and ``shumlib`` may have a slightly different tag depending on when
+  their latest releases were completed.
+* ``um_meta`` should be pointed at your release branch, created above.
 
 
 Checking Metadata and Rose Apps
@@ -131,16 +125,20 @@ file (see the existing line).
 Commit the changes to both the UM and Meta branches.
 
 
-Final Checks
-------------
+Update the UM Module
+--------------------
 
-**UM AUX Changes**
+The UM external libraries on azspice are loaded with a ``um`` module, with two
+module load commands in ``rose-stem/site/meto/family-azspice.cylc``.
 
-If there are changes to the AUX ``main`` in this release, then add a new
-``YYYY.MM.N`` tag to the ``um_aux`` repository and then update the ``ref`` in
-the UM ``dependencies.yaml`` file - commit this to the branch.
+The module for this file lives in ``$UMDIR/modules/modulefiles/um``. If there
+isn't already a new modulefile for this release then copy the previous one,
+updating the name and a few examples of the release number inside. Then update
+the module load commands in ``family-azspice.cylc``.
 
-**Other Points**
+
+Final Checks
+------------
 
 * Check rose-stem/rose-suite.conf?
 
@@ -233,10 +231,7 @@ version from the comparison as we did with tests that use mule-cumf.
 
   .. code-block:: shell
 
-      find ~cylc-run/<suite name>/runN/log/job -path "*rose_ana*" -type f \
-          -name job.status \
-          | xargs grep -l CYLC_JOB_EXIT=ERR \
-          | grep -vE "(scm|netcdf)"
+      find ~/cylc-run/<suite name>/runN/log/job -path "*rose_ana*" -type f -name job.status | xargs grep -l CYLC_JOB_EXIT=ERR | grep -vE "(scm|netcdf)"
 
 The ``meto_update_kgo.sh`` script is stored in SimSys_Scripts. As yourself,
 navigate to ``$UMDIR/SimSys_Scripts/kgo_updates`` directory and run
@@ -297,12 +292,18 @@ host zone as above.
 Review and Commit
 -----------------
 
+Before passing for review, change the ``um_meta`` entry in the
+``dependencies.yaml`` file so that it points back to the MetOffice repo and the
+``YYYY.MM.X`` tag (this won't exist yet but that's fine temporarily).
+
 Ensure all changes are committed to both branches and then create a PR
 targeting main for each of the ``um`` and ``um_meta`` branches and pass
-along for a review and commit.
+along for a review and commit. Once the ``um_meta`` PR has been committed then
+:ref:`tag<tagging>` with ``YYYY.MM.X``.
 
 You and the reviewer should then work through the process of merging main and
-stable together - :ref:`see here for details page<github-releases>`.
+stable together for the UM - :ref:`see here for details page<github-releases>`.
+Finally add the ``YYYY.MM.X`` :ref:`tag<tagging>` to the UM.
 
 
 Install the Release
@@ -380,15 +381,15 @@ Now run the central install group,
 
 .. code-block:: shell
 
-    cylc vip -z g=ex1a_install -S CENTRAL_INSTALL=true -n umx.y_install ./rose-stem
+    cylc vip -z g=ex1a_install -S CENTRAL_INSTALL=true -S USE_MIRRORS=true -n umx.y_install ./rose-stem
 
 Finally we need to install the kgo for the release. Do this by running the
 ``ex1a`` group. Once that is finished, run the kgo install script(sourced from
 the SimSys_Scripts repo).
 
 .. code-block:: shell
 
-    cylc vip -z g=ex1a -n umx.y_kgo ./rose-stem
+    cylc vip -z g=ex1a -S USE_MIRRORS=true -n umx.y_kgo ./rose-stem
 
     # Wait for tests to complete
     python3 SimSys_Scripts/kgo_updates/kgo_update/kgo_update.py -N vnX.Y \