Before we pushing any release packages into the staging repository or the Apache directory. The source code of all OpenWhisk projects are hosted under apache folder at Github. Release managers are responsible for picking up valid hash values or tags for each OpenWhisk project to be released. As we described on the General Specification page, a JSON-format configuration file is used to save the project names with the hash values or tags. Then, source code can be downloaded based on the configuration, and verified the compliance either by some existing tools or programs. If the source code meets the requirements, we can proceed to deploy the OpenWhisk services and other client tools, and run the test cases to check whether the services are up and running, whether the client tools are ready to use, etc.
This release of the source code packages need to have the following features implemented.
All the source code OpenWhisk project is located at the Github website. If a configuration file is in place, we should be able to download the source code, based on the hash values or tags, defined for each specified repository. This feature can be implemented in a bash script, which is able to run both on a local machine or in Travis build.
The script can be named “download_source_code.sh”. When this repository is cloned, go to the home directory of this repository, and run ./download_source_code.sh in a terminal. The source code of OpenWhisk projects should be downloaded to either the specified place or the default place. When a Travis build is kicked off, this script should be called in order to download the source code. It is better to support both Ubuntu and Mac systems.
Work bulletins:
Each source code file needs to have Apache licensing header at the top. We need to implement the verification in the script able to run both locally and in Travis build.
Work bulletins:
Build the source code and deploy the OpenWhisk environment. We need to implement the following bulletins in the script.
Work bulletins:
This step is optional for the release process, but the release manager needs to make sure the code we deliver is in good shape in terms of functionality.
Work bulletins:
We need to prepare these files when release managers are developing the release repository. As we investigated, Apache Tentacles can create the LICENSE and NOTICE report. The current question is: can we run this tools locally, to generate the NOTICE and LICENSE, before we upload artifacts to any repository, like the staging repository?(TBD)
Work bulletins:
Each OpenWhisk project needs to have one compiled package, and one source code package. This is probably where the Maven release plugin can play out. As we have already downloaded the source code of each OpenWhisk repository, Maven command can be used to generate all the artifacts.
One challenge we can think of is that OpenWhisk consists of projects based on different programming languages individually, we need to figure out how to package the artifacts differently for different languages, by using the similar or consistent build environment. OpenWhisk core is based on Scala, CLI is based on Go, wskdeploy is based on Go, api gateway is based on lua, runtime project may be based on its native runtime language, etc.
Another important item in this step is to sign the artifacts cryptographically for the release. We need to figure out how to do it, either in Travis CI, Jenkins pipeline, or any other building tools.
Work bulletins:
Upload the artifacts including source code, compiled packages, etc into the staging repository for vote. This is the staging directory of Apache projects for OpenWhisk.
Work bulletins:
When we reach an agreement on the candidate located in the staging repository, the artifacts need to be move to the Apache
directory for release. This is the release directory of Apache for OpenWhisk.
Work bulletins: