-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
CI tweaks #13875
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.
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
CI tweaks #13875
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice changes, thanks!
| name: Packages | ||
| path: dist | ||
|
|
||
| - name: Download release notes | ||
| uses: actions/download-artifact@v6 | ||
| with: | ||
| name: release-notes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor: the names are inconsistent: Packages vs release-notes. No big deal, up to you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! TIL pypandoc-binary..
If you want better privilege isolation, maybe split pypi-publish into a dedicated job and only have OIDC in there.
Done, now the workflow is like this: Maybe better not to parallelize the generate-gh-release-notes step in case it fails... |
I agree, it does a lot of things and is conceivable it might fail for one reason or another. |
|
I usually generate the change log before packaging but that's because I don't do it before cutting the release. I save it as an artifact and can then commit in later jobs and apply when producing dists. Then I run testing and the publishing job. Everything else is mutated post-PyPI success and can be parallelized sometimes. If you split those last steps into jobs, you can then restart them individually w/o worrying about side effects. Example: https://github.com/cherrypy/cheroot/actions/runs/19050434787 |
…ease Since creating the github release is security sensitive, better to isolate the part of generating the markdown release notes in its own job, such that if e.g. pip/tox/pandoc is compromised it could not in turn compromise the release files.
This installs pandoc from a binary wheel instead of requiring it in the system (apt install in CI). While system pandoc may be more trustworthy, we already trust pypandoc so might as well trust the binary wheels (which from the same project) to make it easier to run.
This fixes the `{.interpreted-text role="func"}` stuff that shows up
with the `md` format which github doesn't support.
See comparison gist:
https://gist.github.com/bluetech/365f5b20f6ed1258439d65768714ddc0
We run all scripts through tox, that's debatable but consistency is more important.
Better to use a recent version, but didn't go for 3.14 maybe it's still too new for some dependencies.
This way each job only gets the permissions it needs.
|
I removed the parallelism. |
A hardening tweak, a fix for the github release markdown rendering, and a couple more changes, please see the commits for details.