Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update release process #410

Merged
merged 1 commit into from
Mar 22, 2023
Merged

Update release process #410

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 0 additions & 49 deletions .github/workflows/release_workflow.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,55 +5,6 @@ on:
types: [published]

jobs:
publish-to-anaconda:
runs-on: ubuntu-latest
timeout-minutes: 10
defaults:
run:
shell: bash -l {0}
steps:
- uses: actions/checkout@v3

- name: Cache Conda
uses: actions/cache@v3
env:
CACHE_NUMBER: 0
with:
path: ~/conda_pkgs_dir
key: ${{ runner.os }}-conda-${{ env.CACHE_NUMBER }}-publish

- name: Set up Conda Environment
uses: conda-incubator/setup-miniconda@v2
with:
activate-environment: "zppy_publish"
channel-priority: strict
python-version: 3.9
auto-update-conda: true
# IMPORTANT: This needs to be set for caching to work properly!
use-only-tar-bz2: true

- name: Additional Conda Config
run: |
conda install anaconda-client conda-build conda-verify
conda config --set anaconda_upload no

- name: Build Conda Package
run: conda build -c conda-forge --output-folder . .

- name: Publish to Anaconda (e3sm channel)
env:
ANACONDA_API_TOKEN: ${{ secrets.ANACONDA_TOKEN }}
run: |
label="main"

for file in noarch/*.tar.bz2; do
if [[ "$file" == noarch/*"rc"*.tar.bz2 ]]; then
label="e3sm_dev"
fi
done

echo Uploading to conda-forge with \'$label\' label
anaconda upload --label $label noarch/*.tar.bz2 --force

publish-docs:
runs-on: ubuntu-latest
Expand Down
39 changes: 26 additions & 13 deletions docs/source/dev_guide/release.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -63,8 +63,13 @@ Bumping the Version

.. _github-release:

Releasing on GitHub
-------------------
Releasing on GitHub: release candidates
---------------------------------------

1. Create a tag for the release candidate at https://github.com/E3SM-Project/zppy/tags.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see a way to create a tag without creating a release. https://stackoverflow.com/questions/64561146/how-do-i-create-a-tag-in-github-without-creating-a-release suggests creating a release and then deleting it. Is it something to do on the command-line side (https://git-scm.com/book/en/v2/Git-Basics-Tagging)?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think using the prerelease feature may be good. The bots won't pick it up as long as it is named with rc, beta, alpha, etc.

Alternatively,

$ git tag -a v0.0.1 -m "test tag"
$ git push origin v0.0.1

https://github.com/mahf708/test-repo-tags

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We currently use the pre-release feature for release-candidates (https://github.com/E3SM-Project/zppy/releases/tag/v2.2.0rc4 for instance). I do like that as it allows me to write up a summary of what's changed between RCs. That said, Xylar does have a point about it confusing people; it's annoying to sort through multiple RCs to get to actual releases.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a wild example, you can see how tensorflow does things: https://github.com/tensorflow/tensorflow/releases/tag/v2.12.0-rc1

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I see. An empty prerelease page may help, but I am not sure. I will defer to Xylar :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That structure is very similar to how I organize the zstash and zppy pre-release and release notes already, albeit with way more detail.


Releasing on GitHub: production releases
----------------------------------------

1. Draft a new release `here <https://github.com/E3SM-Project/zppy/releases>`_.
2. Set `Tag version` to ``v<version>``, **including the "v"**. `@Target` should be ``main``.
Expand All @@ -73,21 +78,29 @@ Releasing on GitHub

* You can scroll through `zppy commits <https://github.com/E3SM-Project/zppy/commits/main>`_ for a list of changes.

5. If this version is a release candidate (``<version>`` appended with ``rc``), checkmark `This is a pre-release`.
6. Click `Publish release`.
7. CI/CD release workflow is automatically triggered.
5. Click `Publish release`.
6. CI/CD release workflow is automatically triggered.

Releasing Anaconda
------------------
Releasing on conda-forge: release candidates
--------------------------------------------

1. Be sure to have already completed :ref:`Releasing On GitHub <github-release>`. This triggers the CI/CD workflow that handles Anaconda releases.
2. Wait until the CI/CD build is successful. You can view all workflows at `All Workflows <https://github.com/E3SM-Project/zppy/actions>`_.
3. Check the https://anaconda.org/e3sm/zppy page to view the newly updated package.
1. Make a PR to `conda-forge <https://github.com/conda-forge/zppy-feedstock/>`_ from your fork of the feedstock. Note that the conda-forge bot does not work for release candidates.

* Start from the current dev branch and update the version number and the sha256 sum manually.
* Set the build number back to 0 if needed.
* Make the dev branch the target of the PR. Then, the package build on conda-forge will end up with the ``e3sm_dev`` label.
Comment on lines +89 to +91
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this section will definitely need clarification, but we can improve the wording when we work on the next release together.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, and yes, you will want either me or @xylar to do the initial swipe at this lest we end up unintentionally producing artifacts (packages). The idea is that you want to "rerender" it locally and then push directly into a new branch. It's much easier to just let us do it though 😸


* Release candidates are assigned the ``e3sm_dev`` label
* Production releases are assigned the ``main`` label
2. Check the https://anaconda.org/conda-forge/zppy page to view the newly updated package. Release candidates are assigned the ``e3sm_dev`` label.

4. Notify the maintainers of the unified E3SM environment about the new release on the `E3SM Confluence site <https://acme-climate.atlassian.net/wiki/spaces/WORKFLOW/pages/129732419/E3SM+Unified+Anaconda+Environment>`_.
Releasing on conda-forge: production releases
---------------------------------------------

1. Be sure to have already completed :ref:`Releasing On GitHub <github-release>`. This triggers the CI/CD workflow that handles Anaconda releases.
2. Wait for a bot PR to come up automatically on conda-forge after the GitHub release. This can happen anywhere from 1 hour to 1 day later.
3. Re-render the PR (see `docs <https://conda-forge.org/docs/maintainer/updating_pkgs.html#rerendering-feedstocks>`_).
4. Merge the PR on conda-forge.
5. Check the https://anaconda.org/conda-forge/zppy page to view the newly updated package. Production releases are assigned the ``main`` label.
6. Notify the maintainers of the unified E3SM environment about the new release on the `E3SM Confluence site <https://acme-climate.atlassian.net/wiki/spaces/WORKFLOW/pages/129732419/E3SM+Unified+Anaconda+Environment>`_.

* Be sure to only update the ``zppy`` version number in the correct version(s) of the E3SM Unified environment.
* This is almost certainly one of the versions listed under “Next versions”. If you are uncertain of which to update, leave a comment on the page asking.
Expand Down