- Quick Start
- Function Characteristics
- PubSub Mechanism
- Expose and Secure Functions
- Data Stream Events
- Debug Functions
- Build Function Images
- Advanced deployment
- Kubeless Configuration
- Use a Custom Apache Kafka
- Install Troubleshooting
- Cloud Providers
- Azure Container Services
- Google Kubernetes Engine
- Development Guide
- Implementing a New Runtime
- Implementing a New Trigger
- Release Flow
Kubeless leverages travis-ci to construct an automated release flow. A release package includes kubeless binaries for multiple platforms (linux and osx are supported) and one yaml file to deploy kubeless controller.
Checks before releasing
Before releasing it is necessary to check that the rest of projects of the Kubeless environment do not present regressions for the new changes. Before creating a new release, deploy Kubeless using the latest commit of master (using the tag "latest" for the controller image). Make sure that the latest image build in Travis for the Kubeless controller is being used. After that, ensure that the following projects support the new version:
If any error is found after doing some manual testing, make sure the error is addressed before doing a release.
Kubeless release flow
A release is triggered by Travis Github Releases and based on GitHub tagging. Once a commit in the master branch is tagged, a travis job will be started to build and upload assets to Github release page under a new release with the tag name. The setup is described at
deploy sections in
before_deploy defines commands executed before releasing. At this stage, we prepare assets which will be uploaded including kubeless binaries and the yaml file. The yaml file is converted from kubeless.jsonnet file using kubecfg. The kubeless-controller is built in format of docker image and push to Bitnami repository on DockerHub. Because we use sha256 digest for labeling docker images to be deployed when installing kubeless, we need to update these digests for the new release.
deploy defines configuration for a github release. API key is encrypted version of our Github token with scope
public_repo. The condition for a release to be triggered is defined at
- it will be triggered once a commit is tagged
- the repository is
- only travis job for
os: linux and
go: 1.8 can do the release
Once the release job has finished a
Draft with the release notes will appear in the releases page. Review the notes and include a summary of the changes included in the release. Delete information that is not useful for the users. Make sure that breaking changes are properly highlighted. After that click on "Publish" for making the new release available for anyone.
Update the rest of projects to use the new version
Note: These steps are suitable for being automated in the Travis release job
Once the new version is available, there are several projects/files that require to be updated in order to point to the latest version:
- Kubeless root README: Update the installation instructions to point to the latest release.
- Kubeless docs site: To point to the latest version in the docs of http://kubeless.io rebuild the last build on https://travis-ci.org/kubeless/kubeless-website.
- Kubeless chart: Update the references for the different images or any other required change in the
chartfolder of this repository.
- Serverless plugin: Update the
KUBELESS_VERSIONenvironment variable in the
.travisfile to point to the latest version.
- [Optional] Brew recipes: An automated PR will be generated in the
homebrew-corerepository with the new version and commit ID. Unless the recipe should contain breaking changes the update will be handled by the homebrew team. If it is not the case the recipe manually.
- KubeApps: Update the reference of the controller image and checkout the kubeless submodule to point to the tagged commit. After that ping a KubeApps maintainer to merge the changes and update the manifests in the KubeApps repository. You can find an example of update here.