search

pypa / gh-action-pypi-publish

The blessed :octocat: GitHub Action, for publishing your :package: distribution files to PyPI, the tokenless way: https://github.com/marketplace/actions/pypi-publish
https://packaging.python.org/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/
BSD 3-Clause "New" or "Revised" License
928 stars 87 forks source link

oidc-exchange: specialize error on PRs from forks #203

Closed woodruffw closed 8 months ago

woodruffw commented 10 months ago

This specializes the token retrieval error handling a bit, providing an alternative error message when the error cause is something that we know can't possibly work due to GitHub's own restrictions on PRs from forks.

Closes #202.

See https://github.com/python-pillow/Pillow/pull/7616.

webknjaz commented 9 months ago

@woodruffw I added one last suggestion for a thing that wasn't obvious when I was checking it out from the mobile client. Looking at your commits, I take it you expect me to use the squash strategy, right?

woodruffw commented 9 months ago

I added one last suggestion for a thing that wasn't obvious when I was checking it out from the mobile client. Looking at your commits, I take it you expect me to use the squash strategy, right?

Thanks! And yeah, that's what I was thinking -- that being said, I can also squash this locally and force-push if that's preferred (including going forwards).

webknjaz commented 8 months ago

Thanks! And yeah, that's what I was thinking -- that being said, I can also squash this locally and force-push if that's preferred (including going forwards).

I usually prefer nice atomic commits and a natural Git merge mode (not squash or rebase) to preserve history. But if that's not observed, I'm okay with selecting a squash mode, as long as it's better and/or requested. If it's not requested, I'll use my best judgement but I still wanted to clarify just in case you have your own preferences. The reason is that the responsibility for writing a good commit message shifts towards the merger in the case of squash compared to merge where the contributor would compose commit individual messages and the maintainer would only be adding something to the merge commit message, not touching the atomic ones.