alitheg commented on code in PR #1264:
URL:
https://github.com/apache/tooling-trusted-releases/pull/1264#discussion_r3287071318
##########
atr/storage/writers/distributions.py:
##########
@@ -302,6 +309,12 @@ async def __upgrade_staging_to_final(
version=version,
).demand(RuntimeError(f"Distribution {tag} not found"))
if existing.staging:
+ # TODO(#751): When remote promotion of artifacts to third party
+ # platforms is implemented, assert here that
existing.staging_revision_key
+ # equals the current Revision.key for the release before flipping
+ # staging to False, so that the artifacts being promoted are
+ # guaranteed to match those that were voted on. The column was
+ # added in #751 for exactly this purpose.
Review Comment:
I could be wrong (@sbp please confirm) - but when I was working in a related
area yesterday I realised that moving to preview (vote) creates a new revision.
You can't create a distribution from the vote page, so the staging revision
will always be one behind the actual revision voted on (even though it's the
same code). In some places in the code (for vote stage access to checks for
example) we use the immediate previous revision. We could do that in the future
check for this, potentially? But it's something to consider more broadly - the
vote stage has a revision with little to no metadata attached. Equally - some
projects won't vote on a distribution so we should make sure that any future
check here is only mandatory if there *was* a staging distribution!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
