Further updates

docs/source/dev_guide/pre_release_testing.rst

@@ -6,21 +6,53 @@ Testing directions for making a release
 
 2. ``cd`` to the ``zppy`` directory.
 
-3. Run ``git log``. The most recent commit should match the most recent commit on https://github.com/E3SM-Project/zppy/commits/main. This ensures that testing will use the latest code changes.
+3. Check out a branch to test on. ::
 
-4. Set up a new development environment. This ensures that testing will use the latest conda changes. Note that you will need to run ``conda remove -n zppy_dev_pre_rc<#> --all`` first if you have previously done this step. ::
+     git fetch upstream main
+     git checkout -b test_pre_rc<#> upstream/main
+
+4. Set up a dev environment for E3SM Diags. ::
+
+     # `cd` to e3sm_diags directory
+     $ git checkout main
+     $ git fetch upstream
+     $ git reset --hard upstream/main
+     $ git log # Should match https://github.com/E3SM-Project/e3sm_diags/commits/main
+     $ mamba clean --all
+     $ mamba env create -f conda-env/dev.yml -n e3sm_diags_<date>
+     $ conda activate e3sm_diags_<date>
+     $ pip install .
+
+5. Make sure you're using the latest packages. In ``tests/integration/utils.py``, do the following:
+
+   * Change the last line ``generate_cfgs()`` to ``generate_cfgs(unified_testing=True)``. If this is not done, then ``zppy`` will simply load the latest officially released E3SM Unified environment by default.
+   * Update ``environment_commands_test`` for the machine you're currently working on. If this is not done, then ``zppy`` will use the existing value, which is likely an old E3SM Unified RC launch script that doesn't even exist anymore. This parameter should be set to the latest E3SM Unified RC launch script, since E3SM Unified is the only environment that all ``zppy`` tasks can run from. For instance, ``ncclimo`` isn't in the ``zppy`` dev environment.
+   * Update ``diags_environment_commands`` to use the environment created in the above step. If this is not done, the ``atm_monthly_180x360_aave_environment_commands`` subtask will use an older dev environment for E3SM Diags than we want.
+
+6. Set up a new development environment. This ensures that testing will use the latest conda changes. Note that you will need to run ``conda remove -n zppy_dev_pre_rc<#> --all`` first if you have previously done this step. ::
 
      mamba clean --all
      mamba env create -f conda/dev.yml -n zppy_dev_pre_rc<#>
      conda activate zppy_dev_pre_rc<#>
      pip install .
 
-5. Run the unit tests with ``python -u -m unittest tests/test_*.py``.
+7. Run the unit tests with ``python -u -m unittest tests/test_*.py``.
+
+   * If there are any failures, fix the code (or tests), and then go back to the above step.
+   * If there are no failures, proceed to the next step.
 
-6. Run the "Commands to run before running integration tests" for the respective machine: `Chrysalis <https://github.com/E3SM-Project/zppy/blob/main/tests/integration/generated/directions_chrysalis.md>`_, `Compy <https://github.com/E3SM-Project/zppy/blob/main/tests/integration/generated/directions_compy.md>`_, `Perlmutter <https://github.com/E3SM-Project/zppy/blob/main/tests/integration/generated/directions_pm-cpu.md>`_. To ensure you don't encounter issues from running ``zppy`` commands simultaneously, wait for all the automatically launched jobs from one run to finish before running ``zppy` again.
+8. Run the "Commands to run before running integration tests" for the current machine. To ensure you don't encounter issues from running ``zppy`` commands simultaneously, wait for all the automatically launched jobs from one run to finish before running ``zppy`` again.
+
+   * `Chrysalis <https://github.com/E3SM-Project/zppy/blob/main/tests/integration/generated/directions_chrysalis.md>`_
+   * `Compy <https://github.com/E3SM-Project/zppy/blob/main/tests/integration/generated/directions_compy.md>`_
+   * `Perlmutter <https://github.com/E3SM-Project/zppy/blob/main/tests/integration/generated/directions_pm-cpu.md>`_
+
+9. Run the integration tests with ``python -u -m unittest tests/integration/test_*.py``. Note that ``test_complete_run.py`` takes approximately 75 minutes to run on Compy.
 
-7. Run the integration tests with ``python -u -m unittest tests/integration/test_*.py``. Note that ``test_complete_run.py`` takes approximately 75 minutes to run on Compy.
+    * If there are any unexpected failures, fix the code, and then go back to step 6.
+    * If there are only expected failures, then update the expected files. Use the "Commands to run to replace outdated expected files" from the links on the above step. Then repeat this step.
+    * If there are no failures at all, proceed to the next step.
 
-8. If there are any unexpected failures, fix the code before making a release, and then go back to step 1. If there are only expected failures, then update the expected files. Use the "Commands to run to replace outdated expected files" from the links on step 6. Then go back to step 7. If there are no failures at all, proceed to step 9.
+11. Make a pull request and merge any changes. This keeps the repo updated with the latest testing configurations.
 
-9. Create the release candidate by following the directions at https://e3sm-project.github.io/zppy/_build/html/main/dev_guide/release.html.
+12. Create the release candidate by following the directions at https://e3sm-project.github.io/zppy/_build/html/main/dev_guide/release.html.

docs/source/dev_guide/release.rst

@@ -12,6 +12,8 @@ In this guide, we'll cover:
 Preparing the Documentation
 ---------------------------
 
+This step is only required for production releases, not release candidates.
+
 1. Checkout a branch
 
    ::
@@ -74,6 +76,8 @@ Releasing on GitHub: release candidates
 	$ git fetch upstream
 	$ git reset --hard upstream/main
 	$ git tag -a v1.1.0rc1 -m "v1.1.0rc1"
+	# Delete the branch from the tbump step. Otherwise, the push command won't work.
+	$ git branch -D v1.1.0rc1
 	$ git push upstream v1.1.0rc1
 
 Releasing on GitHub: production releases
@@ -108,11 +112,13 @@ Releasing on conda-forge: release candidates
 4. Make changes on a local branch: ::
 
      $ git fetch upstream dev
-     $ git checkout -b v1.1.0rc1 upstream/main # You can name the branch anything you want
+     $ git checkout -b v1.1.0rc1 upstream/dev # You can name the branch anything you want
      # In `recipe/meta.yaml`, update the version and sha256 (and the build number if needed):
      {% set version = "1.1.0rc1" %} # Set to your version
      sha256: ... # The sha256 from the previous step
      number: 0 # build > number should always be 0
+     $ git add -A
+     $ git commit -m "v1.1.0rc1"
      $ git push <your fork name> v1.1.0rc1
 
 5. Note that the conda-forge bot does not work for release candidates. So, make a PR manually from your fork of the feedstock to the ``dev`` branch of `conda-forge <https://github.com/conda-forge/zppy-feedstock/>`_. Then, the package build on conda-forge will end up with the ``zppy_dev`` label. You can add the "automerge" label to have the PR automatically merge once CI checks pass.