From 7aeaade2f95e0dc10b4ba4155c92ead16da6b358 Mon Sep 17 00:00:00 2001 From: Nathan Goldbaum Date: Wed, 22 May 2024 16:11:00 -0600 Subject: [PATCH 1/3] Update release instructions Signed-off-by: Nathan Goldbaum --- docs/wiki/dev-guides/Release-Process.md | 44 ++++++++++++++++++------- 1 file changed, 32 insertions(+), 12 deletions(-) diff --git a/docs/wiki/dev-guides/Release-Process.md b/docs/wiki/dev-guides/Release-Process.md index 3d417d0c6..899ebf9f6 100644 --- a/docs/wiki/dev-guides/Release-Process.md +++ b/docs/wiki/dev-guides/Release-Process.md @@ -74,12 +74,9 @@ Follow these steps when it's time to tag a new release. Before doing this, you will need to ensure `bump2version` is installed into your development environment. -> \[!NOTE\] -> The following steps assume you have a personal fork of csp. -> If you are working from the main `Point72/csp` repo, use `origin` -> instead of `upstream` in the git commands. Specifically, -> `git pull origin main --tags` in the step 1, -> and `git push origin main --follow-tags` in step 7. +> The following steps assume you are pushing to the main `Point72/csp` +> repo. If you are working from a personal fork, use `upstream` +> instead of `origin` in all git commands except for the final tag push. 1. Ensure your local clone of `csp` is synced up with GitHub, including any tags that have been pushed since you last synced: @@ -99,8 +96,8 @@ development environment. git checkout -b release/v0.x.x ``` - For example, for a bugfix release, `bump2version` will automatically - update the codebase to use the next bugfix version number if you do: + You can update the version number in the codebase using `bump2version`. For a + bugfix release, you would do: ```bash make patch @@ -108,7 +105,8 @@ development environment. Similarly, `make minor` and `make major` will update the version numbers for minor and major releases, respectively. Double-check - that the version numbers have been updated correctly with `git diff`, and then `git commit -s` the change. + that the version numbers have been updated correctly with + `git diff`, and then `git commit -s` the change. 1. Push your branch to GitHub, and trigger a "full" test run on the branch. @@ -118,7 +116,8 @@ development environment. button is selected, and click the green "Run workflow" button to launch the test run. -1. Propose a pull request from the branch containing the version number updated. Add a link to the successful full test run for reviewers. +1. Propose a pull request from the branch containing the version number updated. + Add a link to the successful full test run for reviewers. 1. Review and merge the pull request. Make sure you delete the branch afterwards. @@ -132,10 +131,10 @@ development environment. git tag v0.2.0 ``` -1. Push the tag to GitHub +1. Push the tag to GitHub using the tag name created in the previous step. ```bash - git push upstream main --follow-tags + git push origin tag v0.2.0 ``` You will need access in the repository settings to be able to push @@ -249,6 +248,27 @@ View at: https://pypi.org/project/csp// ``` +### Releasing to conda-forge + +The conda-forge release process is largely automated. Maintainers who +are listed under the `extra.recipe-maintainers` field in the `csp` +recipe hosted in [the conda-forge feedstock +repository](https://github.com/conda-forge/csp-feedstock/blob/main/recipe/meta.yaml) +should be automatically subscribed to notifications for the +repository. Soon after a new release is uploaded to PyPI, the +`regro-cf-autotick` bot will automatically create a pull request +updating the package version. This may take several hours, you can check +[the status page](https://conda-forge.org/status/#version_updates) if +you are impatient. If the conda-forge package build is green on the pull +request opened by the bot, a package maintainer can merge the pull +request which will publish the new package version to conda-forge. Any +failing CI due to build changes or changes in dependencies should be +fixed by updating the conda recipe stored in the feedstock. See [the +conda-forge +docs](https://conda-forge.org/docs/maintainer/updating_pkgs/#pushing-to-regro-cf-autotick-bot-branch) +for more instructions on updating automatically generated version update +pull requests on conda-forge. + ## Dealing with release mistakes Sometimes releases go wrong. Here is what to do when that happens. This From fafad069aab66aed3c6aee7ac666379ca523a650 Mon Sep 17 00:00:00 2001 From: Tim Paine <3105306+timkpaine@users.noreply.github.com> Date: Tue, 4 Jun 2024 18:12:10 -0400 Subject: [PATCH 2/3] Tweak docs slightly to simplify and avoid duplication Signed-off-by: Tim Paine <3105306+timkpaine@users.noreply.github.com> --- .../dev-guides/Local-Development-Setup.md | 34 +------------------ docs/wiki/dev-guides/Release-Process.md | 24 +++++-------- 2 files changed, 9 insertions(+), 49 deletions(-) diff --git a/docs/wiki/dev-guides/Local-Development-Setup.md b/docs/wiki/dev-guides/Local-Development-Setup.md index 15de91ccf..5dae1abbe 100644 --- a/docs/wiki/dev-guides/Local-Development-Setup.md +++ b/docs/wiki/dev-guides/Local-Development-Setup.md @@ -6,7 +6,6 @@ - [Create your fork](#create-your-fork) - [Configure remotes](#configure-remotes) - [Authenticating with GitHub](#authenticating-with-github) - - [Configure commit signing](#configure-commit-signing) - [Guidelines](#guidelines) ## Step 1: Build CSP from Source @@ -31,19 +30,7 @@ already set that way and click "Create fork". ### Configure remotes Next, you should set some names for the `git` remotes corresponding to -main Point72 repository and your fork. If you started with a clone of -the main `Point72` repository, you could do something like: - -```bash -cd csp -git remote rename origin upstream - -# for SSH authentication -git remote add origin git@github.com:/csp.git - -# for HTTP authentication -git remote add origin https://github.com//csp.git -``` +main Point72 repository and your fork. See the [GitHub Docs](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/configuring-a-remote-repository-for-a-fork) for more information. ### Authenticating with GitHub @@ -59,25 +46,6 @@ or adding a [personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) to avoid the need to type in your password every time you push to your fork. -### Configure commit signing - -Additionally, you will need to configure your local `git` setup and -GitHub account to use [commit -signing](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification). All -commits to the `csp` repository must be signed to increase the -difficulty of a supply-chain attack against the CSP codebase. The -easiest way to do this is to [configure `git` to sign commits with your -SSH -key](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification#ssh-commit-signature-verification). You -can also use a [GPG -key](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification#gpg-commit-signature-verification) -to sign commits. - -In either case, you must also add your public key to your github account -as a signing key. Note that if you have already added an SSH key as an -authentication key, you will need to add it again [as a signing -key](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account). - ## Guidelines After developing a change locally, ensure that both [lints](Build-CSP-from-Source#lint-and-autoformat) and [tests](Build-CSP-from-Source#testing) pass. Commits should be squashed into logical units, and all commits must be signed (e.g. with the `-s` git flag). CSP requires [Developer Certificate of Origin](https://en.wikipedia.org/wiki/Developer_Certificate_of_Origin) for all contributions. diff --git a/docs/wiki/dev-guides/Release-Process.md b/docs/wiki/dev-guides/Release-Process.md index 899ebf9f6..2104deaf3 100644 --- a/docs/wiki/dev-guides/Release-Process.md +++ b/docs/wiki/dev-guides/Release-Process.md @@ -10,6 +10,7 @@ - [Download release artifacts from github actions](#download-release-artifacts-from-github-actions) - [Optionally upload to testpypi to test "pip install"](#optionally-upload-to-testpypi-to-test-pip-install) - [Upload to pypi](#upload-to-pypi) + - [Releasing to conda-forge](#releasing-to-conda-forge) - [Dealing with release mistakes](#dealing-with-release-mistakes) ## Doing a "normal" release @@ -75,8 +76,9 @@ this, you will need to ensure `bump2version` is installed into your development environment. > The following steps assume you are pushing to the main `Point72/csp` -> repo. If you are working from a personal fork, use `upstream` -> instead of `origin` in all git commands except for the final tag push. +> repo. If you are working from a personal fork, use the corresponding +> remote (e.g. `upstream`) instead of `origin` in all git commands. +> Ensure tags are still pushed to `Point72/csp` directly. 1. Ensure your local clone of `csp` is synced up with GitHub, including any tags that have been pushed since you last synced: @@ -250,24 +252,14 @@ https://pypi.org/project/csp// ### Releasing to conda-forge -The conda-forge release process is largely automated. Maintainers who +The `conda-forge` release process is largely automated. Maintainers who are listed under the `extra.recipe-maintainers` field in the `csp` recipe hosted in [the conda-forge feedstock repository](https://github.com/conda-forge/csp-feedstock/blob/main/recipe/meta.yaml) should be automatically subscribed to notifications for the -repository. Soon after a new release is uploaded to PyPI, the -`regro-cf-autotick` bot will automatically create a pull request -updating the package version. This may take several hours, you can check -[the status page](https://conda-forge.org/status/#version_updates) if -you are impatient. If the conda-forge package build is green on the pull -request opened by the bot, a package maintainer can merge the pull -request which will publish the new package version to conda-forge. Any -failing CI due to build changes or changes in dependencies should be -fixed by updating the conda recipe stored in the feedstock. See [the -conda-forge -docs](https://conda-forge.org/docs/maintainer/updating_pkgs/#pushing-to-regro-cf-autotick-bot-branch) -for more instructions on updating automatically generated version update -pull requests on conda-forge. +repository. The [conda-forge maintainer documentation](https://conda-forge.org/docs/maintainer/updating_pkgs/) +has the relevant guidelines and procedures, and should be read thoroughly before +making any changes. ## Dealing with release mistakes From f5fbb6d0b3aafaf3b9cea899c3ead9983b18b3b3 Mon Sep 17 00:00:00 2001 From: Tim Paine <3105306+timkpaine@users.noreply.github.com> Date: Tue, 4 Jun 2024 18:13:32 -0400 Subject: [PATCH 3/3] remove double space in git diff command --- docs/wiki/dev-guides/Release-Process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/wiki/dev-guides/Release-Process.md b/docs/wiki/dev-guides/Release-Process.md index 2104deaf3..b3175dd97 100644 --- a/docs/wiki/dev-guides/Release-Process.md +++ b/docs/wiki/dev-guides/Release-Process.md @@ -108,7 +108,7 @@ development environment. Similarly, `make minor` and `make major` will update the version numbers for minor and major releases, respectively. Double-check that the version numbers have been updated correctly with - `git diff`, and then `git commit -s` the change. + `git diff`, and then `git commit -s` the change. 1. Push your branch to GitHub, and trigger a "full" test run on the branch.