This is an automated email from the ASF dual-hosted git repository.
mrutkowski pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/openwhisk-release.git
The following commit(s) were added to refs/heads/master by this push:
new 115c84d Refine release manager pre-reqs and instructions (#379)
115c84d is described below
commit 115c84d49a69ac2e0936021984c10aab8dcba17c
Author: Matt Rutkowski <mrutk...@us.ibm.com>
AuthorDate: Thu Mar 11 17:46:41 2021 -0600
Refine release manager pre-reqs and instructions (#379)
* Refine release manager pre-reqs and instructions
* Refine release manager pre-reqs and instructions
* Refine release manager pre-reqs and instructions
* Refine release manager pre-reqs and instructions
* Refine release manager pre-reqs and instructions
* Refine release manager pre-reqs and instructions
* Refine release manager pre-reqs and instructions
* Refine release manager pre-reqs and instructions
* Add client-go release config
* Refine release manager pre-reqs and instructions
* Update client-go commit hash in release config
* Upload final release config: client-go-1.2.0.json
* Fix URL path to specific commit hash
---
docs/license_compliance.md | 7 +-
docs/release_instructions.md | 404 +++++++++++++++--------------------
docs/release_manager_setup.md | 141 ++++++++----
release-configs/client-go-1.2.0.json | 15 ++
tools/gen-release-vote.py | 2 +-
5 files changed, 299 insertions(+), 270 deletions(-)
diff --git a/docs/license_compliance.md b/docs/license_compliance.md
index 12f6e44..8c9f48b 100644
--- a/docs/license_compliance.md
+++ b/docs/license_compliance.md
@@ -28,10 +28,12 @@ This document describes how the Apache OpenWhisk project's
source code and relea
## Policies and rules
The Apache OpenWhisk project repositories MUST follow [Apache Release
Policy](http://www.apache.org/legal/release-policy.html#licensing). every
artifact distributed MUST contain only appropriately licensed code per Apache
Licensing Policy. It includes two check points:
+
- Each project repository MUST provide a LICENSE file and a NOTICE file.
- With a few exceptions, source files consisting of works submitted directly
to the ASF by the copyright owner or owner's agent must contain the appropriate
ASF license header. Here are the exceptions:
- + Files without any degree of creativity don't require a license header.
- + Sometimes shorter form of ASF license header can be used if the
recommended Apache source header is not appropriate.
+
+ - Files without any degree of creativity don't require a license header.
+ - Sometimes shorter form of ASF license header can be used if the
recommended Apache source header is not appropriate.
## Project specific rules
@@ -68,7 +70,6 @@ In addition, the recommended type of approved ASF license
header (i.e., "full" o
- Full ASF License headers are always accepted regardless if a "Mini" header
is recommended as best practice.
- Action source files used in performance testing may be added to "[Known
exclusions](#known-exclusions)" when justified.
-
## General Exclusions
In accordance with Apache LICENSE policies, the table below lists general
exclusions by file (type) as agreed to by the project community along with the
justification.
diff --git a/docs/release_instructions.md b/docs/release_instructions.md
index 2b7a420..42f70e9 100644
--- a/docs/release_instructions.md
+++ b/docs/release_instructions.md
@@ -21,75 +21,62 @@
## Release Manager Initial Setup
-If you have never served as a Release Manager (or it has been a while
-since you have done it), first read the
-[Release Manager Setup](release_manager_setup.md) instructions.
-We have scripts that automate many of the tasks a Release Manager must
-perform, but these scripts assume you have followed the instructions
-in the Release Manager Setup before you start executing them.
+If you have never served as a Release Manager (or it has been a while since
you have done it), first read the [Release Manager
Setup](release_manager_setup.md) instructions.
+
+This repository includes scripts that automate many of the tasks a Release
Manager must perform, but these scripts assume you have followed the
instructions in the Release Manager Setup before you start executing them.
## Non-PMC Release Managers
-Actually publishing a release is an official act of the OpenWhisk
-Project Management Committee (PMC). If you are an OpenWhisk Committer,
-but not an OpenWhisk PMC member, you will need to pair-up with a PMC member to
-accomplish some of the steps. In brief, any step that adds or removes
-an artifact from a public distribution channel must be executed by
-an OpenWhisk PMC member.
+Publishing a release is an official act of the OpenWhisk Project Management
Committee (PMC). If you are an OpenWhisk Committer, but not an OpenWhisk PMC
member, you will need to pair-up with a PMC member to
+accomplish some of the steps.
+
+In brief, any step that adds or removes an artifact from a public distribution
channel must be executed by an OpenWhisk PMC member.
## Background Information
-If you are acting as a Release Manager, you should be familiar with
-the Apache Software Foundation's (ASF)
-[Release Creation Process](http://www.apache.org/dev/release-publishing.html)
and
-[Release Policy](http://www.apache.org/legal/release-policy.html).
-The detailed instructions and scripts we provide for Release Managers
-are designed to implement the ASF's policies and procedures in the
-specific context of the OpenWhisk project. However, it is still
-essential that each Release Manager understands the rationale underlying
-the steps they are executing.
+If you are acting as a Release Manager, you should be familiar with the Apache
Software Foundation's (ASF) [Release Creation
Process](http://www.apache.org/dev/release-publishing.html) and [Release
Policy](http://www.apache.org/legal/release-policy.html).
+
+The detailed instructions and scripts we provide for Release Managers are
designed to implement the ASF's policies and procedures in the specific context
of the OpenWhisk project. However, it is still essential that each Release
Manager understands the rationale underlying the steps they are executing.
### Licensing requirements
-All released source code has to be compliant with Apache Licensing
-Policy. In part this is done by adding the LICENSE file and NOTICE file
-to each git repository and by adding Licensing headers to each source code
-file. Please see [License Compliance](license_compliance.md) for
-detailed information on Apache OpenWhisk project policies, rules and
-guidelines.
+All released source code has to be compliant with Apache Licensing Policy. In
part this is done by adding the LICENSE file and NOTICE file to each git
repository and by adding Licensing headers to each source code file. Please
see [License Compliance] (license_compliance.md) for detailed information on
Apache OpenWhisk project policies, rules and guidelines.
### Artifact requirements
-Artifacts for project repository source code and any compiled binaries
-are packaged separately with each artifact being signed
-cryptographically.
+Artifacts for project repository source code and any compiled binaries are
packaged separately with each artifact being signed cryptographically.
### Release Approval
-All Releases must be formally approved via a PMC vote on the dev list.
-A successful release vote must have a minimum of three positive binding
-votes and more positive than negative binding votes MUST be cast.
+All Releases must be formally approved via a PMC vote on the dev list. A
successful release vote must have a minimum of three positive binding votes and
more positive than negative binding votes MUST be cast.
### Release distribution requirements
All release artifacts must be uploaded to project’s designated subdirectory in
the Apache distribution channel
([https://dist.apache.org/repos/dist/](https://dist.apache.org/repos/dist/)).
Specifically, the Apache OpenWhisk project has a subdirectory to publish both
candidate (staged) releases:
-[https://dist.apache.org/repos/dist/dev/openwhisk/](https://dist.apache.org/repos/dist/dev/openwhisk/)
+
+-
[https://dist.apache.org/repos/dist/dev/openwhisk/](https://dist.apache.org/repos/dist/dev/openwhisk/)
+
and approved releases:
-[https://dist.apache.org/repos/dist/release/openwhisk/](https://dist.apache.org/repos/dist/release/openwhisk/).
+-
[https://dist.apache.org/repos/dist/release/openwhisk/](https://dist.apache.org/repos/dist/release/openwhisk/).
+
+Release announcements should not directly refer to the main Apache dist server
for mirrored artifacts (the sources.tar.gz files). Instead they should refer to
the OpenWhisk project download page:
-Release announcements should not directly refer to the main Apache dist server
for mirrored artifacts (the sources.tar.gz files). Instead they should refer to
the OpenWhisk project download page
[https://apache.openwhisk.org/downloads](https://openwhisk.apache.org/downloads)
which is configured to redirect download requests to Apache dist mirrors or
otherwise incorporate a mirroring enabled URL.
+-
[https://apache.openwhisk.org/downloads](https://openwhisk.apache.org/downloads)
+
+which is configured to redirect download requests to Apache dist mirrors or
otherwise incorporate a mirroring enabled URL.
# Step-by-Step Instructions for the Release Process
### Preparing to Make a Release
Before creating release artifacts, the Release Manager should initiate a
community discussion to confirm that we are ready to release the component(s).
It is also good practice to do a quick check of the repositories to confirm
they are release-ready to reduce the odds of needing multiple release
candidates.
- 1. Start a [DISCUSS] thread on the dev list proposing the release. Allow at
least 24 hours for feedback.
- 2. Make sure all unit and integration tests are passing in the repositories
that are being released. Check the [project status
list](../README.md#project-status).
- 3. If a component being released includes a changelog or release notes file,
make sure they are up-to-date.
- 4. If you are releasing either the `openwhisk` or `openwhisk-deploy-kube`
repositories create a release branch in the Apache git repo. Then submit a PR
to that release branch to change all uses of the `nightly` tag to fixed tags
(eg `1.14.0` or `8eb922f`).
+
+1. Start a [DISCUSS] thread on the dev list proposing the release. Allow at
least 24 hours for feedback.
+1. Make sure all unit and integration tests are passing in the repositories
that are being released. Check the [project status
list](../README.md#project-status).
+1. If a component being released includes a changelog or release notes file,
make sure they are up-to-date.
+1. If you are releasing either the `openwhisk` or `openwhisk-deploy-kube`
repositories create a release branch in the Apache git repo. Then submit a PR
to that release branch to change all uses of the `nightly` tag to fixed tags
(eg `1.14.0` or `8eb922f`).
### (Optional) Make a branch to create a Release
@@ -97,42 +84,44 @@ This step is only required when making a release for the
`openwhisk` or `openwhi
1. Create a Release branch with the version name in the upstream repository.
-Please be noted that the branch should be created in the upstream repository,
not a forked repository.
-This branch would not be merged into the master branch and stay as a
standalone branch.
+ > **Important Note:** the release branch should be created in the
upstream repository, *not a forked repository*.
-```bash
-$ git checkout -b 1.0.0
-$ git push upstream 1.0.0
-```
+ This branch would not be merged into the master branch and stay as a
standalone branch.
+
+ ```bash
+ $ git checkout -b 1.0.0
+ $ git push upstream 1.0.0
+ ```
-2. Add commits to this branch to make a Release.
+1. Add commits to this branch to make a Release.
-Sometimes, it is required to add a release specific commit. For example, the
Docker image tag for runtimes should be updated to other than `nightly`.
-The Release Manager is supposed to open relevant PRs directly against the
release branch and merge them.
+ Sometimes, it is required to add a release specific commit. For example,
the Docker image tag for runtimes should be updated to other than `nightly`.
-3. Open a PR with the release branch.
+ The Release Manager is supposed to open relevant PRs directly against the
release branch and merge them.
-You can make sure the branch passes all CI tests whenever the branch changes.
+1. Open a PR with the release branch.
+ You can make sure the branch passes all CI tests whenever the branch
changes.
-4. Trigger the Jenkins job to build Docker images.
+1. Trigger the Jenkins job to build Docker images.
-Docker images built with the release version is required to run the standalone
OpenWhisk without any local build.
+ Docker images built with the release version is required to run the
standalone OpenWhisk without any local build.
-The following job is intended to build a release branch and publish images to
the Docker hub.
-The Release Manager should update the branch specifier in the Jenkins job.
+ The following job is intended to build a release branch and publish images
to the Docker hub.
-https://ci-builds.apache.org/job/OpenWhisk/job/OpenWhisk-DockerHub-ReleaseBranch/
+ The Release Manager should update the branch specifier in the Jenkins job.
-This job is supposed to be disabled after the release process is over.
+ -
https://ci-builds.apache.org/job/OpenWhisk/job/OpenWhisk-DockerHub-ReleaseBranch/
+
+ This job is supposed to be disabled after the release process is over.
### Defining the Release Contents
The contents of a release are defined by a JSON configuration file.
-To create one for your release, make a copy of
[config_template.json](../tools/config_template.json)
-and edit to provide the version information, list of repositories, and details
for each repository.
-After creating your config, commit it to
[../release-configs](../release-configs) to
-provide historical documentation of project releases.
+
+To create one for your release, make a copy of
[config_template.json](../tools/config_template.json) and edit to provide the
version information, list of repositories, and details for each repository.
+
+After creating your config, commit it to
[../release-configs](../release-configs) to provide historical documentation of
project releases.
```
{
@@ -158,72 +147,75 @@ provide historical documentation of project releases.
}
}
```
- - **versioning**: Defines the release version and the release candidate
number.
- - **RepoList**: Defines the list of OpenWhisk repositories being released.
- - For every repository in `RepoList`, we name-mangle it to convert `-` into
`_` and use the
- mangled name as a key whose value is an object that defines
- - name: User level name of the component
- - hash: git commit hash being released
- - repository: URL of the repository
- - branch: git branch being released (`master` or a release branch name)
-
-**Important Note 1:** If you are releasing a Node.js package which
-contains a `package.json`, you should make sure the `version`
-specified in `package.json` matches your release version. If you
-also have a `package-lock.json` file, it too must have a matching
-`version` property. See additional tips for [releasing npm
-packages](#publishing-to-npm).
-
-**Important Note 2:** If you are releasing the `openwhisk` or
`openwhisk-deploy-kube` repositories,
-the branch and commit hash in the release contents should be the release
branch and the latest commit hash in the release branch.
-Please be careful not to use the `master` branch.
-
+
+- **versioning**: Defines the release version and the release candidate number.
+- **RepoList**: Defines the list of OpenWhisk repositories being released.
+- For every repository in `RepoList`, we name-mangle it to convert `-` into
`_` and use the mangled name as a key whose value is an object that defines:
+
+ - `name`: User level name of the component
+ - `hash`: git commit hash being released
+ - `repository`: URL of the repository
+ - `branch`: git branch being released (`master` or a release branch name)
+
+> **Important Note 1:** If you are releasing a Node.js package which contains
a `package.json`, you should make sure the `version` specified in
`package.json` matches your release version. If you also have a
`package-lock.json` file, it too must have a matching `version` property. See
additional tips for [releasing npm packages](#publishing-to-npm).
+
+> **Important Note 2:** If you are releasing the `openwhisk` or
`openwhisk-deploy-kube` repositories, the branch and commit hash in the release
contents should be the release branch and the latest commit hash in the
release branch. Please be careful not to use the `master` branch.
### Create Release Candidates
-From the [tools directory](../tools), execute the script
-[build_release.sh](../tools/build_release.sh)
-providing the config.json file as an argument.
-Using `../stagingArea` as scratch space, this script will clone the
-source repositories, package them into compressed tarballs, and create
-the checksum and detached PGP signature files.
-```
-./build_release.sh ../release-configs/<MY_RELEASE_CONFIG>.json
[<MY_APACHE_GPG_KEY_ID>]
-```
+From the [tools directory](../tools), execute the script
[build_release.sh](../tools/build_release.sh) providing the config.json file as
an argument.
-*Note:* `build_release.sh` uses your system default GPG key to sign the
release. To use an alternate key,
-specify the _key id_ as a second argument. Omit this value to use the default
key.
+Using `../stagingArea` as scratch space, this script will clone the source
repositories, package them into compressed tarballs, and create the checksum
and detached PGP signature files.
-Next, verify the release artifacts by running
[local_verify.sh](../tools/local_verify.sh). This
-script will run rcverify.sh against your local artifacts.
+```sh
+$ cd tools
+$ ./build_release.sh ../release-configs/<MY_RELEASE_CONFIG>.json
[<MY_APACHE_GPG_KEY_ID>]
```
+
+> **Important Note:** the `build_release.sh` script uses your system default
GPG key to sign the release. To use an alternate key, specify the
`MY_APACHE_GPG_KEY_ID` as a second argument. Omit this value to use the default
key.
+
+If successful, your release artifacts (i.e., `.tar.gz`,`tar.gz.asc`, and
`.tar.gz.sha512`) should be in the `../stagingArea/artifacts` folder.
+
+### Verify the release artifacts
+
+Next, verify the release artifacts by running
[local_verify.sh](../tools/local_verify.sh). This script will run `rcverify.sh`
against your local artifacts.
+
+```sh
./local_verify.sh ../release-configs/<MY_RELEASE_CONFIG>.json
```
-TODO: We should also run Apache Rat (https://creadur.apache.org/rat/)
-as part of `local_verify.sh`; for now it is a recommended best practice
-to run Apache Rat by hand on each of your .tar.gz files. Download RAT
-and invoke it on the .tar.gz file like:
-```
+> **TODO**: In the future we would like to run the Apache Rat scanning tool
(https://creadur.apache.org/rat/) as part of `local_verify.sh`.
+
+For now, It is a recommended best practice to run the Apache Rat tool manually
on each of your `.tar.gz` files.
+
+Download RAT and invoke it on the `.tar.gz` file like:
+
+```sh
java -jar apache-rat-0.13.jar stagingArea/artifacts/<release-name>.tar.gz
```
+### Commit release artifacts to staging
+
If the release candidates pass all checks, commit them to the staging svn:
-```
+
+```sh
./upload_to_staging.sh ../release-configs/<MY_RELEASE_CONFIG>.json
```
+You can verify the files were committed under the directory specified in your
`<MY_RELEASE_CONFIG>.json` file's `pre_release_version` key's value (e.g.,
`rc1`) here:
+
+- https://dist.apache.org/repos/dist/dev/openwhisk/
+
### Initiate a Release Vote
Initiate a release vote on the dev list.
-Use the [gen-release-vote.py](../tools/gen-release-vote.py)
-script to create the body of the voting email.
-```
+Use the [gen-release-vote.py](../tools/gen-release-vote.py) script to create
the body of the voting email.
+
+```sh
./gen-release-vote.py ../release-configs/<MY_RELEASE_CONFIG>.json
```
-This script accepts a [mailer configuration
file](https://github.com/apache/openwhisk-release/blob/master/tools/mail-config-template.yaml)
which you can use
-to also send the vote email directly to the mailing list. _You should dry run
this command with `-n` to sanity check the vote notice before it is sent._
+This script accepts a [mailer configuration
file](https://github.com/apache/openwhisk-release/blob/master/tools/mail-config-template.yaml)
which you can use to also send the vote email directly to the mailing list.
_You should dry run this command with `-n` to sanity check the vote notice
before it is sent._
```
./gen-release-vote.py ../release-configs/<MY_RELEASE_CONFIG>.json -mc
<MY_MAILER_CONFIG>.yaml
@@ -231,33 +223,25 @@ to also send the vote email directly to the mailing list.
_You should dry run th
### Report Vote Result
-When the vote can be closed (at least 72 hours and minimum number of
-binding votes cast), the Release Manager will respond to the voting
-thread modifying the subject to start with `[RESULT][VOTE]...`
-announcing the result of the vote. If the vote has sufficient -1 votes
-cast, the Release Manager may declare that the vote has failed without
-waiting the full 72 hours.
+When the vote can be closed (at least 72 hours and minimum number (3) of `+1`
binding votes cast), the Release Manager will respond to the voting thread
modifying the subject to start with `[RESULT][VOTE]...` announcing the result
of the vote.
+
+If the vote has sufficient `-1` votes cast, the Release Manager may declare
that the vote has failed without waiting the full 72 hours.
-If the vote is successful, the Release Manager proceeds with
-publishing the release and cleaning up as described below.
+If the vote is successful, the Release Manager proceeds with publishing the
release and cleaning up as described below.
-It the vote is unsuccessful, correct whatever issues were raised and
-restart the process with new candidate releases. Update your
-`config.json` file by incrementing the `rc` number and changing git
-hashes.
+It the vote is unsuccessful, correct whatever issues were raised and restart
the process with new candidate releases. Update your `config.json` file by
incrementing the `rc` number and changing git hashes.
### Publishing a Successful Release to Apache Dist Servers
-**Only a PMC member can perform this step**
+> **Only a PMC member can perform this step**
-After a successful vote, the release manager will commit the artifacts
-being released to the `openwhisk` subdir of the Apache dist svn.
+After a successful vote, the release manager will commit the artifacts being
released to the `openwhisk` subdir of the Apache dist svn.
-The [`upload_to_dist.sh`](../tools/upload_to_dist.sh) script automates the
copy & svn add operations, but it
-assumes that every file found in the release candidate subdir should be
released.
-If this is not true (e.g., multiple parallel release votes), then the upload
-must be performed manually.
-```
+The [`upload_to_dist.sh`](../tools/upload_to_dist.sh) script automates the
copy & svn add operations, but it assumes that every file found in the release
candidate subdir should be released.
+
+If this is not true (e.g., multiple parallel release votes), then the upload
must be performed manually.
+
+```sh
./upload_to_dist.sh ../release-configs/<MY_RELEASE_CONFIG>.json
```
@@ -266,10 +250,9 @@ Assuming the expected set of files were added, commit them:
cd ../stagingArea/svn_release && svn commit -m "Apache OpenWhisk X.Y.Z
release of <Component Description>"
```
-Relatively soon after doing the svn commit, you should receive an email like
-the one shown below from reporter.apache.org asking you to add release data
-to its database information.
-```
+Relatively soon after doing the svn commit, you should receive an email like
the one shown below from reporter.apache.org asking you to add release data to
its database information.
+
+```text
Hi,
This is an automated email from reporter.apache.org.
I see that you just pushed something to our release repository for the
'openwhisk' project
@@ -279,101 +262,83 @@ r35971 at 2019-09-23 16:07:53 +0000 (Mon, 23 Sep 2019)
Apache OpenWhisk CLI Group v1.0.0
If you are a PMC member of this project, we ask that you log on to:
-<URL ELIDED>
+<URL OMITTED>
and add your release data (version and date) to the database.
-...elided rest of email...
+...omitted rest of email...
```
-Please follow the link and perform the update; this information is
-quite useful for drafting our periodic reports to the ASF Board.
+
+Please follow the link and perform the update; this information is quite
useful for drafting our periodic reports to the ASF Board.
### Tag GitHub repos
-Each GitHub repository needs to be tagged. Unfortunately, the naming
conventions for
-tagging vary across the OpenWhisk project repositories and therefore we have
not
-yet attempted to automate this step.
+Each GitHub repository needs to be tagged. Unfortunately, the naming
conventions for tagging vary across the OpenWhisk project repositories and
therefore we have not yet attempted to automate this step.
-For each released repository, the Release Manager should examine the existing
set of
-tags (`git tag`) and then add a new tag following the same convention using the
-git commit hash from <MY_RELEASE_CONFIG>.json. After tagging a repo, push the
tag.
+For each released repository, the Release Manager should examine the existing
set of tags (`git tag`) and then add a new tag following the same convention
using the git commit hash from <MY_RELEASE_CONFIG>.json. After tagging a repo,
push the tag.
-Many of the GitHub repositories are configured to build binary artifacts in
response
-to new tags being committed. Monitor the build process and ensure that all
expected
-artifacts are created for each tag you commit.
+Many of the GitHub repositories are configured to build binary artifacts in
response to new tags being committed. Monitor the build process and ensure
that all expected artifacts are created for each tag you commit.
-There are some slightly outdated, but much more detailed comments
-on [release tagging](tag_release.md) available if you need a reminder
-of the git commands to use.
+There are some slightly outdated, but much more detailed comments on [release
tagging](tag_release.md) available if you need a reminder of the git commands
to use.
### Create GitHub releases
-After pushing the tags, you should go to the GitHub Releases for
-each released project and "Draft a new release" using the tag you just
-pushed. If the project contains a CHANGELOG or RELEASENOTES, copy that
-information into the release description.
+After pushing the tags, you should go to the GitHub Releases for each released
project and "Draft a new release" using the tag you just pushed.
+
+Update the project's:
+
+- `CHANGELOG` or `RELEASENOTES` to include the release versions, description
and a list of all commits since the last release. Copy that information into
the release description.
### Dockerhub updates
-**Only a PMC member can push images to the openwhisk organization on
dockerhub**
-
-If the components you released build docker images, then you should
-build the docker images locally, tag them with the release version
-(following the naming scheme for the repo), push the new images to
-dockerhub using the whiskbot dockerhub id, and update the `latest`
-tag to point to the new images.
-
-### Rippling changes for openwhisk-runtime-* releases
-
-If you are releasing a new version of an openwhisk-runtime, then
-once the updated images are available on dockerhub you should submit
-a PR to openwhisk-deploy-kube to update the docker imageTags in
-that project's `helm/openwhisk/runtimes.json`.
-
-If you released a new version of openwhisk-runtime-go, then you need
-to update tag information in the Dockerfiles of all actionloop based
-action runtimes. To support reproducible builds, we always use a
-fixed-tag (and almost always a release tag) when pulling code
-from openwhisk-runtime-go into other runtime projects to build the
-actionloop go proxy.
-The current list of actionloop based Dockerfiles is:
-+ openwhisk-runtime-java/core/java8actionloop/Dockerfile
-+ openwhisk-runtime-php/core/php7.3Action/Dockerfile
-+ openwhisk-runtime-php/core/php7.4Action/Dockerfile
-+ openwhisk-runtime-php/core/php8.0Action/Dockerfile
-+ openwhisk-runtime-python/core/python2ActionLoop/Dockerfile
-+ openwhisk-runtime-python/core/python3ActionLoop/Dockerfile
-+ openwhisk-runtime-python/core/python3AiActionLoop/Dockerfile
-+ openwhisk-runtime-ruby/core/ruby2.6ActionLoop/Dockerfile
-+ openwhisk-runtime-rust/core/rust1.34/Dockerfile
-+ openwhisk-runtime-swift/core/swift42Action/Dockerfile
-+ openwhisk-runtime-swift/core/swift51Action/Dockerfile
-+ openwhisk-runtime-swift/core/swift53Action/Dockerfile
-
-If you released a new version of openwhisk-runtime-docker, then you need
-to update tag information in the Dockerfiles of openwhisk-runtime-python.
+> **Only a PMC member can push images to the openwhisk organization on Docker
Hub**
+
+If the components you released build docker images, then you should build the
docker images locally, tag them with the release version (following the naming
scheme for the repo).
+
+Push the new images to the [openwhisk
dockerhub](https://hub.docker.com/u/openwhisk) using the whiskbot dockerhub id,
and update the `latest` tag to point to the new images.
+
+### Rippling changes for openwhisk-runtime-- releases
+
+If you are releasing a new version of an openwhisk runtime (e.g.,
`openwhisk-runtime-python`), then once the updated images are available on
[dockerhub](https://hub.docker.com/u/openwhisk) you should submit a PR to
openwhisk-deploy-kube to update the docker imageTags in that project's
`helm/openwhisk/runtimes.json`.
+
+If you released a new version of openwhisk-runtime-go, then you need to update
tag information in the `Dockerfiles` of all actionloop based action runtimes.
+
+To support reproducible builds, we always use a fixed-tag (and almost always a
release tag) when pulling code from openwhisk-runtime-go into other runtime
projects to build the actionloop go proxy.
+
+The current list of "actionloop" based Dockerfiles is:
+
+- openwhisk-runtime-java/core/java8actionloop/Dockerfile
+- openwhisk-runtime-php/core/php7.3Action/Dockerfile
+- openwhisk-runtime-php/core/php7.4Action/Dockerfile
+- openwhisk-runtime-php/core/php8.0Action/Dockerfile
+- openwhisk-runtime-python/core/python2ActionLoop/Dockerfile
+- openwhisk-runtime-python/core/python3ActionLoop/Dockerfile
+- openwhisk-runtime-python/core/python3AiActionLoop/Dockerfile
+- openwhisk-runtime-ruby/core/ruby2.6ActionLoop/Dockerfile
+- openwhisk-runtime-rust/core/rust1.34/Dockerfile
+- openwhisk-runtime-swift/core/swift42Action/Dockerfile
+- openwhisk-runtime-swift/core/swift51Action/Dockerfile
+- openwhisk-runtime-swift/core/swift53Action/Dockerfile
+
+If you released a new version of `openwhisk-runtime-docker`, then you need to
update tag information in the Dockerfiles of `openwhisk-runtime-python`.
+
To support reproducible builds, we always use a fixed-tag
-(and almost always a release tag) when pulling code from
openwhisk-runtime-docker
-into other runtime projects to build their images.
+(and almost always a release tag) when pulling code from
`openwhisk-runtime-docker` into other runtime projects to build their images.
### Publishing to npm
-**Only a PMC member can publish to npm**
+> **Only a PMC member can publish to npm**
-The openwhisk-client-js, openwhisk-composer, and openwhisk-wskdebug
-project release npm packages built from each source release. The
-Release Manager should build and publish these packages manually using
-the openwhisk-bot credentials found in the npmjs.txt file in the
-accounts subdir of the PMC private svn.
+The `openwhisk-client-js`, `openwhisk-composer`, and `openwhisk-wskdebug`
projects release npm packages built from each source release. The Release
Manager should build and publish these packages manually using the
openwhisk-bot credentials found in the `npmjs.txt` file in the accounts subdir
of the PMC private svn.
Some tips:
-* Login as the openwhisk-bot using `npm login`.
-* The `version` specified in `package.json` (and `package-lock.json`
+
+- Login as the openwhisk-bot using `npm login`.
+- The `version` specified in `package.json` (and `package-lock.json`
if it exists) should match the release version. If they don't you need
to fix the release.
-* Confirm that `npm pack` does not report any errors. Then delete the
-generated `.tgz` file.
-* Confirm the list of files that will bundled using `npm publish --dry-run`.
-* To publish the distribution, use `npm publish --public`.
+- Confirm that `npm pack` does not report any errors. Then delete the
generated `.tgz` file.
+- Confirm the list of files that will bundled using `npm publish --dry-run`.
+- To publish the distribution, use `npm publish --public`.
If you are releasing a new version of the openwhisk-client-js package,
then after the new version of the `openwhisk` package is published on
@@ -385,22 +350,17 @@ can help you find all the places to change.
### Homebrew
-If you released a new version of openwhisk-cli, then submit a PR
-to Homebrew to publish the new cli version.
+If you released a new version of openwhisk-cli, then submit a PR to Homebrew
to publish the new cli version.
### Helm Repository
-If you released
[openwhisk-deploy-kube](https://github.com/apache/openwhisk-deploy-kube/), you
need to update the Helm
-repository we provide at https://openwhisk.apache.org/charts.
+If you released
[openwhisk-deploy-kube](https://github.com/apache/openwhisk-deploy-kube/), you
need to update the Helm repository we provide at
https://openwhisk.apache.org/charts.
+
Perform the following steps:
+
1. On the release branch of openwhisk-deploy-kube, run `helm package
helm/openwhisk`.
-2. Add the resulting `openwhisk.tgz` to the GitHub release for
openwhisk-deploy-kube
-3. In [openwhisk-website](https://github.com/apache/openwhisk-website/),
submit a PR to update
[charts/index.yaml](https://github.com/apache/openwhisk-website/tree/master/charts)
to include
- the new chart version. This will take a little care, since `helm repo
index`
- defaults to assuming that the `.tgz` files are in the same directory as
- the `index.yaml`, and we are hosting them elsewhere. Be sure to just add a
stanza
- for the new release with a URL to the GitHub release download and to not
- remove any of the existing stanzas for previous release.
+1. Add the resulting `openwhisk.tgz` to the GitHub release for
openwhisk-deploy-kube
+1. In [openwhisk-website](https://github.com/apache/openwhisk-website/),
submit a PR to update
[charts/index.yaml](https://github.com/apache/openwhisk-website/tree/master/charts)
to include the new chart version. This will take a little care, since `helm
repo index` defaults to assuming that the `.tgz` files are in the same
directory as the `index.yaml`, and we are hosting them elsewhere. Be sure to
just add a stanza for the new release with a URL to the GitHub release download
an [...]
### Update Downloads Page
@@ -409,25 +369,17 @@ refer to the newly released versions.
### Announcing the Release
-For all normal releases you should wait at least 24 hours before
-announcing the release to allow time for Apache Dist mirrors to
-be updated with the newly released artifacts. You must also wait
-until the PR to update the website has been merged and the
-change appears on the website (successful Jenkins job to rebuild website).
+For all normal releases you should wait at least 24 hours before announcing
the release to allow time for Apache Dist mirrors to be updated with the newly
released artifacts. You must also wait until the PR to update the website has
been merged and the change appears on the website (successful Jenkins job to
rebuild website).
-When announcing a release, you must use the URL of the OpenWhisk Downloads
-page (or some other URL that supports mirroring). Do not include a direct
-link to the dist.apache.org svn server.
+When announcing a release, you must use the URL of the OpenWhisk Downloads
page (or some other URL that supports mirroring). Do not include a direct link
to the dist.apache.org svn server.
-Releases should always be announced to d...@openwhisk.apache.org.
-Releases can optionally be announced to annou...@apache.org at the discretion
-of the release manager.
+- Releases should always be announced to `d...@openwhisk.apache.org`.
+- Releases can optionally be announced to `annou...@apache.org` at the
discretion of the release manager.
### Post-release cleanup
1. Remove the release candidate files from the staging svn.
-2. If there is a prior release, remove it from the release svn
-(all releases are automatically archived, removing an old release
+1. If there is a prior release, remove it from the release svn (all releases
are automatically archived, removing an old release
from dist does not remove it from the archive).
-3. Disable the Jenkins job to build and push Docker images to Docker hub if
you released the `openwhisk` or `openwhisk-deploy-kube` repositories.
-4. Close the PR for the release branch if you released the `openwhisk` or
`openwhisk-deploy-kube` repositories.
+1. Disable the Jenkins job to build and push Docker images to Docker hub if
you released the `openwhisk` or `openwhisk-deploy-kube` repositories.
+1. Close the PR for the release branch if you released the `openwhisk` or
`openwhisk-deploy-kube` repositories.
diff --git a/docs/release_manager_setup.md b/docs/release_manager_setup.md
index c140fc4..dea6c16 100644
--- a/docs/release_manager_setup.md
+++ b/docs/release_manager_setup.md
@@ -25,68 +25,129 @@ Currently all Release Managers have either MacOS or Linux
workstations. The scripting/automation assumes one of these two
platforms.
-In addition to all the tools assumed to be installed for building
-OpenWhisk, you will also need the following packages installed:
-- svn
-- jq
-- expect
-- gpg or gnupg
+In addition to all the tools assumed to be installed for building OpenWhisk,
you will also need the following packages installed:
+
+- [Subversion](https://subversion.apache.org/packages.html) (svn) - client for
Apache's source code management system
+- [GnuPG](https://www.gnupg.org/) (gpg) *or an OpenPGP-compatible equivalent*
- for generating and managing signing keys and sign release artifacts
+- [jq](https://stedolan.github.io/jq/) (jq) - a lightweight JSON processor
+- [expect](https://en.wikipedia.org/wiki/Expect) - automates release scripts
that expect user input
## Clone this repository
-You may want to fork the repo and then clone your fork. Setup to use
-the same GitHub workflows you use for other OpenWhisk repositories to
-which you contribute.
+You will need to fork this `openwhisk-release` repository and then clone your
fork. Setup to use the same GitHub workflows you use for other OpenWhisk
repositories to which you contribute.
+
+The scripts/automation in this project assume a local clone and create/use
working directories and staging areas within that clone.
-The scripts/automation in this project assume a local clone and
-create/use working directories and staging areas within that clone.
-Staging areas are listed in the `.gitignore` for the repository to
-avoid accidental commits of generated artifacts.
+> Note: Staging areas are listed in the `.gitignore` for the repository to
avoid accidental commits of generated artifacts.
## Get a local svn checkout of our distribution directories
-The Apache distribution servers are managed by committing/removing
-files from project-specific directory trees in an svn repository.
+The Apache distribution servers are managed by committing/removing files from
project-specific directory trees in an svn repository.
+
+You can run the script [tools/checkout_svn.sh](../tools/checkout_svn.sh) to
create a local checkout of these repositories at the path expected by the rest
of the scripts.
-You can run the script [tools/checkout_svn.sh](../tools/checkout_svn.sh)
-to create a local checkout of these repositories at the path expected
-by the rest of the scripts.
+For example, run the script from within the root of your local clone of the
`openwhisk-release` repository:
+```sh
+$ ./tools/checkout_svn.sh
+
+Checkout staging and release SVN to the working directory.
+Checked out revision 46582.
+A stagingArea/svn_staging/rc1
+A stagingArea/svn_release/20.11
+A
stagingArea/svn_release/20.11/openwhisk-package-alarms-2.2.0-sources.tar.gz
+A stagingArea/svn_release/openwhisk-runtime-php-1.16.0-sources.tar.gz
+A stagingArea/svn_release/openwhisk-runtime-php-1.16.0-sources.tar.gz.asc
+...
+```
-## Signing Keys
+## Signing Keys
-All release artifacts are accompanied by cryptographic signatures
-according to Apache release policy.
+All release artifacts are accompanied by cryptographic signatures according to
Apache release policy.
+
+The ASF requires you to use a PGP key pair that:
+
+- uses the `RSA` algorithm,
+- has your `usern...@apache.org` email address as one of its associated
identifiers,
+- `does not expire` and
+- has the recommended key length of `4096` bits.
+
+See https://www.apache.org/dev/release-signing.html for a full explanation and
list of technical requirements.
### Create a PGP key pair
-You will need a PGP key pair. The key must have your
-usern...@apache.org as one of its associated user ids.
+#### GPG Example
+
+The following command will prompt you for to supply all the values needed by
the ASF and override defaults:
+
+```sh
+$ gpg --full-gen-key
+```
+
+> Note: You do not need to supply a `comment` as part of the signature.
+
+### Publish your public key to the project KEYS file
+
+The KEYS file is a plain-text file containing the public key signatures of the
release managers (and optionally other committers) for the project.
+
+Each signature in the KEYS file is comprised of the key's signature followed
by the ASCII-armored, exported copy of it.
+
+> **Only a PMC member can commit changes to the KEYS file**
+
+Once you have your PGP key pair, append your public key to our [KEYS
file](https://dist.apache.org/repos/dist/release/openwhisk/KEYS) in your local
svn clone and commit the change.
-See https://www.apache.org/dev/release-signing.html for the technical
-requirements for your signing key and instructions on creating one if
-you don't already have an acceptable one.
+> **The KEYS file is append only. Once a key has been used to sign a release
it cannot be removed from the KEYS file.**
-Currently ASF recommends using a 4096 bit RSA key to sign releases.
+The commands to export your key and append it (depending on your PGP client)
can be found at the very top of the
[`KEYS`](https://dist.apache.org/repos/dist/release/openwhisk/KEYS) file
itself, and are also replicated below:
-### Publish your public key to the project KEYS file.
+#### GPG Example (recommended)
-**Only a PMC member can commit changes to the KEYS file**
+Apache recommends [GNU Privacy Guard (GnuPG)](https://www.gnupg.org/), an
open-source, OpenPGP compatible implementation.
-Once you have your PGP key pair, append your public key to our
-[KEYS file](https://dist.apache.org/repos/dist/release/openwhisk/KEYS)
-in your local svn clone and commit the change.
+You can show your key's signature with this command:
-**Our KEYS file is append only. Once a key has been used to sign a release it
cannot be removed from the KEYS file.**
+```sh
+$ gpg --list-sigs <your name>
+```
+
+where `<your name>` is the one entered when generating the key.
+
+In order to submit your public key to a public key server, you first have to
produce an ASCII-armored copy of it:
-The commands to export your key (depending on your PGP client) can be found at
the very top of the KEYS file,
-and are also replicated below:
+```sh
+$ gpg --armor --export <your name>
```
-Developers:
- pgp -kxa <your name> and append it to KEYS
- (pgpk -ll <your name> && pgpk -xa <your name>) >> KEYS.
- (gpg --list-sigs <your name>
- && gpg --armor --export <your name>) >> KEYS.
+
+Append both your key's signature and ASCII-armored public key to the KEYS file:
+
+```sh
+(gpg --list-sigs <your name> && gpg --armor --export <your name>) >> KEYS
```
+> *In recent releases of GnuPG, the- `gpg` and `gpg2` *commands utilize the
same code and should be viewed as equivalent in any legacy instructions.*
+
+#### PGPK Example
+
+You can show your key's fingerprint (i.e., signature) with this command:
+
+```sh
+$ pgpk -ll
+```
+In order to submit your public key to a public key server, you first have to
produce an ASCII-armored copy of it:
+
+```sh
+pgpk -xa smith
+```
+
+Append both your key's fingerprint and ASCII-armored public key to the KEYS
file:
+
+```sh
+(pgpk -ll <your name> && pgpk -xa <your name>) >> KEYS
+```
+
+#### PGP Example
+
+```sh
+pgp -kxa <your name> # and append it to KEYS file manually
+```
diff --git a/release-configs/client-go-1.2.0.json
b/release-configs/client-go-1.2.0.json
new file mode 100644
index 0000000..d2b951b
--- /dev/null
+++ b/release-configs/client-go-1.2.0.json
@@ -0,0 +1,15 @@
+{
+ "versioning": {
+ "version": "1.2.0",
+ "pre_release_version": "rc1"
+ },
+ "RepoList": [
+ "openwhisk-client-go"
+ ],
+ "openwhisk_client_go": {
+ "name": "OpenWhisk Client Go",
+ "hash": "87edc23647174648fe52939201ebb276e0899f83",
+ "repository": "https://github.com/apache/openwhisk-client-go.git";,
+ "branch": "master"
+ }
+}
diff --git a/tools/gen-release-vote.py b/tools/gen-release-vote.py
index c95fd25..f21aa3d 100755
--- a/tools/gen-release-vote.py
+++ b/tools/gen-release-vote.py
@@ -90,7 +90,7 @@ def currentGitHead():
return res.strip()
def gitHashes(components):
- s = map(lambda r: "* %s: %s\n %s/commits/%s\n %s\n %s\n %s\n" %
(r.name, r.hash, r.url, r.hash, r.artifacts.tgz, r.artifacts.asc,
r.artifacts.sha), components)
+ s = map(lambda r: "* %s: %s\n %s/commit/%s\n %s\n %s\n %s\n" %
(r.name, r.hash, r.url, r.hash, r.artifacts.tgz, r.artifacts.asc,
r.artifacts.sha), components)
return '\n'.join(list(s))
def rcverify(components, version):
