瀏覽代碼

Merge pull request #19795 from jfrazelle/release-checklist

some cleanup to release checklist
Tibor Vass 9 年之前
父節點
當前提交
4da9cd5df6
共有 1 個文件被更改,包括 47 次插入41 次删除
  1. 47 41
      project/RELEASE-CHECKLIST.md

+ 47 - 41
project/RELEASE-CHECKLIST.md

@@ -205,10 +205,14 @@ open the PR against the "release" branch instead of accidentally against
 
 
 ### 7. Build release candidate rpms and debs
 ### 7. Build release candidate rpms and debs
 
 
+**NOTE**: It will be a lot faster if you pass a different graphdriver with
+`DOCKER_GRAPHDRIVER` than `vfs`.
+
 ```bash
 ```bash
 docker build -t docker .
 docker build -t docker .
 docker run \
 docker run \
     --rm -t --privileged \
     --rm -t --privileged \
+    -e DOCKER_GRAPHDRIVER=aufs \
     -v $(pwd)/bundles:/go/src/github.com/docker/docker/bundles \
     -v $(pwd)/bundles:/go/src/github.com/docker/docker/bundles \
     docker \
     docker \
     hack/make.sh binary build-deb build-rpm
     hack/make.sh binary build-deb build-rpm
@@ -222,42 +226,42 @@ another docker/docker directory in bundles. This next step assumes you have
 a checkout of the docker source code at the same commit you used to build, with
 a checkout of the docker source code at the same commit you used to build, with
 the artifacts from the last step in `bundles`.
 the artifacts from the last step in `bundles`.
 
 
+**NOTE:** If you put a space before the command your `.bash_history` will not
+save it. (for the `GPG_PASSPHRASE`).
+
 ```bash
 ```bash
 docker build -t docker .
 docker build -t docker .
 docker run --rm -it --privileged \
 docker run --rm -it --privileged \
-    -v /local/path/to/your/repos:/volumes/repos \
+    -v /volumes/repos:/volumes/repos \
     -v $(pwd)/bundles:/go/src/github.com/docker/docker/bundles \
     -v $(pwd)/bundles:/go/src/github.com/docker/docker/bundles \
     -v $HOME/.gnupg:/root/.gnupg \
     -v $HOME/.gnupg:/root/.gnupg \
     -e DOCKER_RELEASE_DIR=/volumes/repos \
     -e DOCKER_RELEASE_DIR=/volumes/repos \
     -e GPG_PASSPHRASE \
     -e GPG_PASSPHRASE \
     -e KEEPBUNDLE=1 \
     -e KEEPBUNDLE=1 \
     docker \
     docker \
-    hack/make.sh release-deb release-rpm
+    hack/make.sh release-deb release-rpm sign-repos generate-index-listing
 ```
 ```
 
 
-### 9. Sign the repos with your GPG key
-
-
-```bash
-./hack/make/sign-repos
-```
+### 9. Upload the changed repos to wherever you host
 
 
-### 10. Upload the changed repos to wherever you host
+For example, above we bind mounted `/volumes/repos` as the storage for
+`DOCKER_RELEASE_DIR`. In this case `/volumes/repos/apt` can be synced with
+a specific s3 bucket for the apt repo and `/volumes/repos/yum` can be synced with
+a s3 bucket for the yum repo.
 
 
-### 11. Publish release candidate binaries
+### 10. Publish release candidate binaries
 
 
 To run this you will need access to the release credentials. Get them from the
 To run this you will need access to the release credentials. Get them from the
 Core maintainers.
 Core maintainers.
 
 
-Replace "..." with the respective credentials:
-
 ```bash
 ```bash
 docker build -t docker .
 docker build -t docker .
 
 
+# static binaries are still pushed to s3
 docker run \
 docker run \
-    -e AWS_S3_BUCKET=test.docker.com \ # static binaries are still pushed to s3
-    -e AWS_ACCESS_KEY="..." \
-    -e AWS_SECRET_KEY="..." \
+    -e AWS_S3_BUCKET=test.docker.com \
+    -e AWS_ACCESS_KEY \
+    -e AWS_SECRET_KEY \
     -i -t --privileged \
     -i -t --privileged \
     docker \
     docker \
     hack/release.sh
     hack/release.sh
@@ -266,7 +270,7 @@ docker run \
 It will run the test suite, build the binaries and upload to the specified bucket,
 It will run the test suite, build the binaries and upload to the specified bucket,
 so this is a good time to verify that you're running against **test**.docker.com.
 so this is a good time to verify that you're running against **test**.docker.com.
 
 
-### 12. Purge the cache!
+### 11. Purge the cache!
 
 
 After the binaries are uploaded to test.docker.com and the packages are on
 After the binaries are uploaded to test.docker.com and the packages are on
 apt.dockerproject.org and yum.dockerproject.org, make sure
 apt.dockerproject.org and yum.dockerproject.org, make sure
@@ -300,7 +304,7 @@ We recommend announcing the release candidate on:
 - The [docker-maintainers](https://groups.google.com/a/dockerproject.org/forum/#!forum/maintainers) group
 - The [docker-maintainers](https://groups.google.com/a/dockerproject.org/forum/#!forum/maintainers) group
 - Any social media that can bring some attention to the release candidate
 - Any social media that can bring some attention to the release candidate
 
 
-### 13. Iterate on successive release candidates
+### 12. Iterate on successive release candidates
 
 
 Spend several days along with the community explicitly investing time and
 Spend several days along with the community explicitly investing time and
 resources to try and break Docker in every possible way, documenting any
 resources to try and break Docker in every possible way, documenting any
@@ -350,7 +354,7 @@ git push -f $GITHUBUSER bump_$VERSION
 Repeat step 6 to tag the code, publish new binaries, announce availability, and
 Repeat step 6 to tag the code, publish new binaries, announce availability, and
 get help testing.
 get help testing.
 
 
-### 14. Finalize the bump branch
+### 13. Finalize the bump branch
 
 
 When you're happy with the quality of a release candidate, you can move on and
 When you're happy with the quality of a release candidate, you can move on and
 create the real thing.
 create the real thing.
@@ -366,9 +370,9 @@ git commit --amend
 
 
 You will then repeat step 6 to publish the binaries to test
 You will then repeat step 6 to publish the binaries to test
 
 
-### 15. Get 2 other maintainers to validate the pull request
+### 14. Get 2 other maintainers to validate the pull request
 
 
-### 16. Build final rpms and debs
+### 15. Build final rpms and debs
 
 
 ```bash
 ```bash
 docker build -t docker .
 docker build -t docker .
@@ -379,7 +383,7 @@ docker run \
     hack/make.sh binary build-deb build-rpm
     hack/make.sh binary build-deb build-rpm
 ```
 ```
 
 
-### 17. Publish final rpms and debs
+### 16. Publish final rpms and debs
 
 
 With the rpms and debs you built from the last step you can release them on the
 With the rpms and debs you built from the last step you can release them on the
 same server, or ideally, move them to a dedicated release box via scp into
 same server, or ideally, move them to a dedicated release box via scp into
@@ -387,47 +391,49 @@ another docker/docker directory in bundles. This next step assumes you have
 a checkout of the docker source code at the same commit you used to build, with
 a checkout of the docker source code at the same commit you used to build, with
 the artifacts from the last step in `bundles`.
 the artifacts from the last step in `bundles`.
 
 
+**NOTE:** If you put a space before the command your `.bash_history` will not
+save it. (for the `GPG_PASSPHRASE`).
+
 ```bash
 ```bash
 docker build -t docker .
 docker build -t docker .
 docker run --rm -it --privileged \
 docker run --rm -it --privileged \
-    -v /local/path/to/your/repos:/volumes/repos \
+    -v /volumes/repos:/volumes/repos \
     -v $(pwd)/bundles:/go/src/github.com/docker/docker/bundles \
     -v $(pwd)/bundles:/go/src/github.com/docker/docker/bundles \
     -v $HOME/.gnupg:/root/.gnupg \
     -v $HOME/.gnupg:/root/.gnupg \
     -e DOCKER_RELEASE_DIR=/volumes/repos \
     -e DOCKER_RELEASE_DIR=/volumes/repos \
     -e GPG_PASSPHRASE \
     -e GPG_PASSPHRASE \
     -e KEEPBUNDLE=1 \
     -e KEEPBUNDLE=1 \
     docker \
     docker \
-    hack/make.sh release-deb release-rpm
+    hack/make.sh release-deb release-rpm sign-repos generate-index-listing
 ```
 ```
 
 
-### 18. Sign the repos with your GPG key
-
-
-```bash
-./hack/make/sign-repos
-```
+### 17. Upload the changed repos to wherever you host
 
 
-### 19. Upload the changed repos to wherever you host
+For example, above we bind mounted `/volumes/repos` as the storage for
+`DOCKER_RELEASE_DIR`. In this case `/volumes/repos/apt` can be synced with
+a specific s3 bucket for the apt repo and `/volumes/repos/yum` can be synced with
+a s3 bucket for the yum repo.
 
 
-### 20. Publish final binaries
+### 18. Publish final binaries
 
 
 Once they're tested and reasonably believed to be working, run against
 Once they're tested and reasonably believed to be working, run against
 get.docker.com:
 get.docker.com:
 
 
 ```bash
 ```bash
 docker build -t docker .
 docker build -t docker .
+# static binaries are still pushed to s3
 docker run \
 docker run \
-    -e AWS_S3_BUCKET=get.docker.com \ # static binaries are still pushed to s3
-    -e AWS_ACCESS_KEY="..." \
-    -e AWS_SECRET_KEY="..." \
+    -e AWS_S3_BUCKET=get.docker.com \
+    -e AWS_ACCESS_KEY \
+    -e AWS_SECRET_KEY \
     -i -t --privileged \
     -i -t --privileged \
     docker \
     docker \
     hack/release.sh
     hack/release.sh
 ```
 ```
 
 
-### 21. Purge the cache!
+### 19. Purge the cache!
 
 
-### 22. Apply tag and create release
+### 20. Apply tag and create release
 
 
 It's very important that we don't make the tag until after the official
 It's very important that we don't make the tag until after the official
 release is uploaded to get.docker.com!
 release is uploaded to get.docker.com!
@@ -446,12 +452,12 @@ You can see examples in this two links:
 https://github.com/docker/docker/releases/tag/v1.8.0
 https://github.com/docker/docker/releases/tag/v1.8.0
 https://github.com/docker/docker/releases/tag/v1.8.0-rc3
 https://github.com/docker/docker/releases/tag/v1.8.0-rc3
 
 
-### 23. Go to github to merge the `bump_$VERSION` branch into release
+### 21. Go to github to merge the `bump_$VERSION` branch into release
 
 
 Don't forget to push that pretty blue button to delete the leftover
 Don't forget to push that pretty blue button to delete the leftover
 branch afterwards!
 branch afterwards!
 
 
-### 24. Update the docs branch
+### 22. Update the docs branch
 
 
 You will need to point the docs branch to the newly created release tag:
 You will need to point the docs branch to the newly created release tag:
 
 
@@ -470,7 +476,7 @@ distributed CDN system) is flushed. The `make docs-release` command will do this
 _if_ the `DISTRIBUTION_ID` is set correctly - this will take at least 15 minutes to run
 _if_ the `DISTRIBUTION_ID` is set correctly - this will take at least 15 minutes to run
 and you can check its progress with the CDN Cloudfront Chrome addon.
 and you can check its progress with the CDN Cloudfront Chrome addon.
 
 
-### 25. Create a new pull request to merge your bump commit back into master
+### 23. Create a new pull request to merge your bump commit back into master
 
 
 ```bash
 ```bash
 git checkout master
 git checkout master
@@ -484,14 +490,14 @@ echo "https://github.com/$GITHUBUSER/docker/compare/docker:master...$GITHUBUSER:
 Again, get two maintainers to validate, then merge, then push that pretty
 Again, get two maintainers to validate, then merge, then push that pretty
 blue button to delete your branch.
 blue button to delete your branch.
 
 
-### 26. Update the VERSION files
+### 24. Update the VERSION files
 
 
 Now that version X.Y.Z is out, time to start working on the next! Update the
 Now that version X.Y.Z is out, time to start working on the next! Update the
 content of the `VERSION` file to be the next minor (incrementing Y) and add the
 content of the `VERSION` file to be the next minor (incrementing Y) and add the
 `-dev` suffix. For example, after 1.5.0 release, the `VERSION` file gets
 `-dev` suffix. For example, after 1.5.0 release, the `VERSION` file gets
 updated to `1.6.0-dev` (as in "1.6.0 in the making").
 updated to `1.6.0-dev` (as in "1.6.0 in the making").
 
 
-### 27. Rejoice and Evangelize!
+### 25. Rejoice and Evangelize!
 
 
 Congratulations! You're done.
 Congratulations! You're done.