A monorepo containing jupyter-blocks and jupyter-tidyblocks. Blockly extension for JupyterLab.
Merge pull request #88 from QuantStack/updateReleaseInfo
Update release information
authored by
Denisa Checiu
and committed by
GitHub
a858e27c
2d305c22
+39
-8
+39
-8
RELEASE.md
+39
-8
RELEASE.md
···
58
58
59
59
## Automated releases with the Jupyter Releaser
60
60
61
-
The extension repository should already be compatible with the Jupyter Releaser. But
62
-
the GitHub repository and the package managers need to be properly set up. Please
63
-
follow the instructions of the Jupyter Releaser [checklist](https://jupyter-releaser.readthedocs.io/en/latest/how_to_guides/convert_repo_from_repo.html).
61
+
The extension repository should already be compatible with the Jupyter Releaser.
62
+
63
+
Check out the [workflow documentation](https://jupyter-releaser.readthedocs.io/en/latest/get_started/making_release_from_repo.html) for more information.
64
64
65
65
Here is a summary of the steps to cut a new release:
66
66
67
+
- Add tokens to the [Github Secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets) in the repository:
68
+
- `ADMIN_GITHUB_TOKEN` (with "public_repo" and "repo:status" permissions); see the [documentation](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token)
69
+
- `NPM_TOKEN` (with "automation" permission); see the [documentation](https://docs.npmjs.com/creating-and-viewing-access-tokens)
70
+
- Set up PyPI
71
+
72
+
<details><summary>Using PyPI trusted publisher (modern way)</summary>
73
+
74
+
- Set up your PyPI project by [adding a trusted publisher](https://docs.pypi.org/trusted-publishers/adding-a-publisher/)
75
+
- The _workflow name_ is `publish-release.yml` and the _environment_ should be left blank.
76
+
- Ensure the publish release job as `permissions`: `id-token : write` (see the [documentation](https://docs.pypi.org/trusted-publishers/using-a-publisher/))
77
+
78
+
</details>
79
+
80
+
<details><summary>Using PyPI token (legacy way)</summary>
81
+
82
+
- If the repo generates PyPI release(s), create a scoped PyPI [token](https://packaging.python.org/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/#saving-credentials-on-github). We recommend using a scoped token for security reasons.
83
+
84
+
- You can store the token as `PYPI_TOKEN` in your fork's `Secrets`.
85
+
86
+
- Advanced usage: if you are releasing multiple repos, you can create a secret named `PYPI_TOKEN_MAP` instead of `PYPI_TOKEN` that is formatted as follows:
87
+
88
+
```text
89
+
owner1/repo1,token1
90
+
owner2/repo2,token2
91
+
```
92
+
93
+
If you have multiple Python packages in the same repository, you can point to them as follows:
94
+
95
+
```text
96
+
owner1/repo1/path/to/package1,token1
97
+
owner1/repo1/path/to/package2,token2
98
+
```
99
+
100
+
</details>
101
+
67
102
- Go to the Actions panel
68
103
- Run the "Step 1: Prep Release" workflow
69
104
- Check the draft changelog
70
105
- Run the "Step 2: Publish Release" workflow
71
106
72
-
> [!NOTE]
73
-
> Check out the [workflow documentation](https://jupyter-releaser.readthedocs.io/en/latest/get_started/making_release_from_repo.html)
74
-
> for more information.
75
-
76
107
## Publishing to `conda-forge`
77
108
78
109
If the package is not on conda forge yet, check the documentation to learn how to add it: https://conda-forge.org/docs/maintainer/adding_pkgs.html
79
110
80
-
Otherwise a bot should pick up the new version publish to PyPI, and open a new PR on the feedstock repository automatically.
111
+
Otherwise a bot should pick up the new version publish to PyPI, and open a new PR on the feedstock repository automatically.