When release runs in upload mode (that is, with -upload flag), it goes through 3 high level stages:

1. uploads files to GCS
2. waits for edge cache
3. uploads payloads to golang.org

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.

CC @golang/release, @dr2chase.