Before starting, it helpfully checks for gcloud Application Default Credentials and refuses to continue if not (see code here). This is needed for step 1, uploading files to GCS.
A different set of permissions is needed for step 3, uploading payloads to golang.org. Specifically, a valid gomote token that's been added to validUser is needed.
What can currently happen is if release -upload is run and step 3 fails (e.g., due to a missing gomote token), then it is difficult to recover from that state. Rerunning release -upload after fixing the gomote token will fail at step 1, because the files will have been uploaded, and permissions for release managers by default allow them to add files, not overwrite existing ones.
This pitfall can be improved in a few ways:
add a check that a gomote token is present before starting (done in CL 315929)
this is trivial to implement, and will likely catch most instances
consider making it so that release -upload can be restarted safely without needing manual intervention
for example, skip over files that have been uploaded successfully instead of attempting to reupload, or modify permissions if it's safe to always allow file overwriting
I'll send a CL to resolve the first bullet point before the next release.
It's helpful to check that required credentials exist before starting
the upload operation. That way, if the gomote token is missing, the
user will be told right away, rather than the operation failing midway.
Trust: Dmitri Shuralyov <email@example.com>
Trust: Alexander Rakoczy <firstname.lastname@example.org>
Reviewed-by: Carlos Amedee <email@example.com>
Reviewed-by: Alexander Rakoczy <firstname.lastname@example.org>