зеркало из https://github.com/golang/build.git
83da5c54f1
We don't want any files in the release staging directory from a previous releasebot run to have a chance to influence a future run. Start using a temporary directory inside <work>/release-staging to prevent that from happening. I considered cleaning the <work>/release-staging directory, but relying on new temporary directories instead of os.RemoveAll seems safer. Users can clean their go-releasebot-work directory themselves if they wish. Change-Id: I2ca38267559aa356992faf7cbec9441c102aba45 Reviewed-on: https://go-review.googlesource.com/c/build/+/191166 Reviewed-by: Alexander Rakoczy <alex@golang.org> |
||
---|---|---|
.. | ||
README.md | ||
gcs.go | ||
git.go | ||
github.go | ||
http.go | ||
main.go | ||
markdown.go |
README.md
golang.org/x/build/cmd/releasebot
Command releasebot runs a Go release.
The release happens in two stages:
- the
prepare
stage checks preconditions, and if needed makes the release commit and mails it for review; - the
release
stage runs after the release commit (if any) is merged, and it tags, builds and cleans up the release.
At the moment only minor and beta releases are supported.
Permissions
The user running a release will need:
- A GitHub personal access token with the
public_repo
scope in~/.github-issue-token
, and an account with write access to golang/go - gomote access and a token in your name
- gcloud application default credentials, and an account with GCS access to golang-org for bucket golang-release-staging
release-manager
group membership on Gerrit
NOTE: all but the Gerrit permission are ensured by the bot on startup.