Why the 2 separate jobs? I was thinking a simpler approach, like the one we follow in Scrapy, may be best.

@Gallaecio as mentioned in #1307 (and in the action's README), having a second workflow for publish reduces the usage of the protected ID token (and environment) by arbitrary execution: only the download and publish actions get access to it. Future changes to the build process won't be able to publish packages without maintainer knowledge.

Interesting.

But if the build process would be compromised, how would this help? The attacker would already be able to modify the files being uploaded without us noticing. And I thought credential sniffing was not much of an issue with trusted publishing anyway, since the tokens involved are short-lived.

Best practice is to reduce attack surface, not to hope you've thought of every scenario.

Ask example scenario is that the attacker exfiltrates and uses the token (to publish a release), then fails the CI job. The new package's release may be unnoticed for some time, affecting users.

At least with the separate job, you know that a release has been made, and can optionally download the wheel to validate.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.63%. Comparing base (8cdcf80) to head (16922fd).

@@ Coverage Diff @@
## master #1309 +/- ##
=======================================
 Coverage 96.63% 96.63% 
=======================================
 Files 235 235 
 Lines 2915 2915 
=======================================
 Hits 2817 2817 
 Misses 98 98 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.