@@ -19,55 +19,15 @@ need python 3.6+ to run this tool.
19193 . Verify that all unit and integration tests for the last commit have passed.
2020
21214 . Run ` releasetool start ` . Select "minor" or "patch" for the release type. This will bump the
22- artifact versions, ask you to edit release notes, and create the release pull request.
22+ artifact versions, ask you to edit release notes, and create the release pull request. When
23+ prompted, select yes for autorelease.
2324
2425 ** Note:** be sure to make these notes nice as they will be used for the release notes as well.
2526
26- ## Pushing a release to Maven using Kokoro
27+ 5 . When tests pass on the release PR and you have a review from a code owner, merge the release PR.
28+ This will trigger automation to stage and release google-cloud-java.
2729
28- To manually publish the artifacts to Maven (rather than using Kokoro), you will need to follow the
29- "Additional setup for manual publishing" steps below and follow the instructions in the
30- "Manually publishing" section.
31-
32- 1 . Trigger the ` google-cloud-java/release/stage ` Kokoro job and wait for it to complete. This will
33- stage the built artifacts and prepare them for publishing.
34-
35- 2 . Look through the logs for the ` google-cloud-java/release/stage ` and find the staging repository
36- ids used. They will look like ` comgoogleapi-XYZ ` and ` comgooglecloud-XYZ ` .
37-
38- 3 . Promote or drop the staged repository.
39-
40- a. To publish the staged repository, trigger the ` google-cloud-java/release/promote ` Kokoro job for
41- each staging repository. To specify the staging repository, add an environment variable
42- configuration with ` STAGING_REPOSITORY_ID=<staging repository id> ` from the UI. ** Note: thi
43- will need to be run for each staging repository. It may take a few hours for the released
44- versions to be available for users to download.**
45-
46- b. To drop (abort) the staged repository, trigger the ` google-cloud-java/release/drop ` Kokoro job
47- with the same staging repository id configuration as if you were publishing.
48-
49- ## Publish Javadoc
50-
51- 1 . Run ` git clean -x -f -d ` to put the repo in a clean state.
52-
53- 2 . Locally build the repo by running ` mvn install -DskipTests ` .
54-
55- 3 . Run ` python utilities/stage_sites.py ` . This script checks out ` gh-pages ` branch of the
56- repository, builds the documentation site and javadocs, copies them to the branch and commits it.
57- This script does not push the docs and it must be done manually on the later step. The script
58- assumes that there is no directory called ` tmp_gh-pages ` in the repository root. If it is
59- present, remove it before running the script.
60-
61- 4 . Run ` cd tmp_gh-pages && git push && cd .. ` .
62-
63- 5 . (Optional) Run ` rm -rf tmp_gh-pages ` to remove the generated docs directory from your local
64- machine.
65-
66- ## Tag the release
67-
68- 1 . Run ` releasetool tag ` to publish a release on Github. It will list the last few merged PRs.
69- Select the newly merged release PR. Releasetool will create the GitHub release with notes
70- extracted from the pull request and tag the new release.
30+ 6 . After the artifacts have been pushed, automation will publish the javadocs to googleapis.dev
7131
7232## Prepare the next snapshot version
7333
0 commit comments