Skip to content

Conversation

@bluetech
Copy link
Member

@bluetech bluetech commented Nov 3, 2025

A hardening tweak, a fix for the github release markdown rendering, and a couple more changes, please see the commits for details.

@bluetech bluetech added the skip news used on prs to opt out of the changelog requirement label Nov 3, 2025
Copy link
Member

@nicoddemus nicoddemus left a comment

Choose a reason for hiding this comment

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

Nice changes, thanks!

Comment on lines 118 to 132
name: Packages
path: dist

- name: Download release notes
uses: actions/download-artifact@v6
with:
name: release-notes
Copy link
Member

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.

Copy link
Member

@webknjaz webknjaz left a 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.

@bluetech
Copy link
Member Author

bluetech commented Nov 4, 2025

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:

  package → publish-to-pypi → push-tag ┐
        ↓                              ├→ create-github-release
        └─→ generate-gh-release-notes ─┘

Maybe better not to parallelize the generate-gh-release-notes step in case it fails...

@nicoddemus
Copy link
Member

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.

  package → generate-gh-release-notes → publish-to-pypi → push-tag → create-github-release

@webknjaz
Copy link
Member

webknjaz commented Nov 4, 2025

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.
@bluetech
Copy link
Member Author

bluetech commented Nov 4, 2025

I removed the parallelism.

@bluetech bluetech merged commit a28c08e into pytest-dev:main Nov 4, 2025
33 checks passed
@bluetech bluetech deleted the ci-tweaks branch November 4, 2025 18:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

skip news used on prs to opt out of the changelog requirement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants