We use analytics and cookies to understand site traffic. Information about your use of our site is shared with Google for that purpose. Learn more.
Setup from scratch
-
- Ensure that your
GOBIN
directory (by default$(go env GOPATH)/bin
) is in yourPATH
. - Check it’s working by running
go version
.- If it doesn’t work, check the install location, usually
/usr/local/go
, is on yourPATH
.
- If it doesn’t work, check the install location, usually
- Ensure that your
-
Sign one of the contributor license agreements below.
-
Clone the repo:
git clone https://github.com/googleapis/google-cloud-go
-
Change into the checked out source:
cd google-cloud-go
-
Fork the repo and add your fork as a secondary remote (this is necessary in order to create PRs).
Which module to release?
The Go client libraries have several modules. Each module does not strictly correspond to a single library - they correspond to trees of directories. If a file needs to be released, you must release the closest ancestor module.
To see all modules:
$ cat `find . -name go.mod` | grep module
module cloud.google.com/go
module cloud.google.com/go/bigtable
module cloud.google.com/go/firestore
module cloud.google.com/go/bigquery
module cloud.google.com/go/storage
module cloud.google.com/go/datastore
module cloud.google.com/go/pubsub
module cloud.google.com/go/spanner
module cloud.google.com/go/logging
The cloud.google.com/go
is the repository root module. Each other module is
a submodule.
So, if you need to release a change in bigtable/bttest/inmem.go
, the closest
ancestor module is cloud.google.com/go/bigtable
- so you should release a new
version of the cloud.google.com/go/bigtable
submodule.
If you need to release a change in asset/apiv1/asset_client.go
, the closest
ancestor module is cloud.google.com/go
- so you should release a new version
of the cloud.google.com/go
repository root module. Note: releasing
cloud.google.com/go
has no impact on any of the submodules, and vice-versa.
They are released entirely independently.
Test failures
If there are any test failures in the Kokoro build, releases are blocked until the failures have been resolved.
How to release cloud.google.com/go
- Check for failures in the continuous Kokoro build. If there are any failures in the most recent build, address them before proceeding with the release.
- Navigate to
~/code/gocloud/
and switch to master. git pull
- Run
git tag -l | grep -v beta | grep -v alpha
to see all existing releases. The current latest tag$CV
is the largest tag. It should look something likevX.Y.Z
(note: ignore allLIB/vX.Y.Z
tags - these are tags for a specific library, not the module root). We’ll call the current version$CV
and the new version$NV
. - On master, run
git log $CV...
to list all the changes since the last release. NOTE: You must manually visually parse out changes to submodules [1] (thegit log
is going to show you things in submodules, which are not going to be part of your release). - Edit
CHANGES.md
to include a summary of the changes. cd internal/version && go generate && cd -
- Commit the changes, push to your fork, and create a PR.
- Wait for the PR to be reviewed and merged. Once it’s merged, and without
merging any other PRs in the meantime:
a. Switch to master.
b.
git pull
c. Tag the repo with the next version:git tag $NV
. d. Push the tag to origin:git push origin $NV
- Update the releases page
with the new release, copying the contents of
CHANGES.md
.
How to release a submodule
We have several submodules, including cloud.google.com/go/logging
,
cloud.google.com/go/datastore
, and so on.
To release a submodule:
(these instructions assume we’re releasing cloud.google.com/go/datastore
- adjust accordingly)
- Check for failures in the continuous Kokoro build. If there are any failures in the most recent build, address them before proceeding with the release. (This applies even if the failures are in a different submodule from the one being released.)
- Navigate to
~/code/gocloud/
and switch to master. git pull
- Run
git tag -l | grep datastore | grep -v beta | grep -v alpha
to see all existing releases. The current latest tag$CV
is the largest tag. It should look something likedatastore/vX.Y.Z
. We’ll call the current version$CV
and the new version$NV
. - On master, run
git log $CV.. -- datastore/
to list all the changes to the submodule directory since the last release. - Edit
datastore/CHANGES.md
to include a summary of the changes. cd internal/version && go generate && cd -
- Commit the changes, push to your fork, and create a PR.
- Wait for the PR to be reviewed and merged. Once it’s merged, and without
merging any other PRs in the meantime:
a. Switch to master.
b.
git pull
c. Tag the repo with the next version:git tag $NV
. d. Push the tag to origin:git push origin $NV
- Update the releases page
with the new release, copying the contents of
datastore/CHANGES.md
.
Appendix
1: This should get better as submodule tooling matures.