Skip to content

Commit 8fd2c03

Browse files
committed
Not adopting the releaser quite yet, it would break the versioning
backend/frontend
1 parent d0e0334 commit 8fd2c03

File tree

3 files changed

+0
-152
lines changed

3 files changed

+0
-152
lines changed

.github/workflows/prep-release.yml

Lines changed: 0 additions & 41 deletions
This file was deleted.

.github/workflows/publish-release.yml

Lines changed: 0 additions & 57 deletions
This file was deleted.

RELEASE.md

Lines changed: 0 additions & 54 deletions
Original file line numberDiff line numberDiff line change
@@ -55,57 +55,3 @@ To publish the frontend part of the extension as a NPM package, do:
5555
npm login
5656
npm publish --access public
5757
```
58-
59-
## Automated releases with the Jupyter Releaser
60-
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-
65-
Here is a summary of the steps to cut a new release:
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-
102-
- Go to the Actions panel
103-
- Run the "Step 1: Prep Release" workflow
104-
- Check the draft changelog
105-
- Run the "Step 2: Publish Release" workflow
106-
107-
## Publishing to `conda-forge`
108-
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
110-
111-
Otherwise a bot should pick up the new version publish to PyPI, and open a new PR on the feedstock repository automatically.

0 commit comments

Comments
 (0)