The Appsody CLI depends on a number of assets:
- The
Appsody Controller
, which is available here. The controller version to pull is located in theMakefile
asCONTROLLER_VERSION
variable. The version is updated manually as needed, there is no automatic update when a new controller is release. However, the dependent controller version does need to be released first, as the build process for the Appsody CLI retrieves the controller binaries and does not build them. Once the dependent controller has been released, a Pull Request with theCONTROLLER_VERSION
changes to theMakefile
needs to be created and merged before continuing on with the CLI release. - The
debian-builder
Docker image, which is built separately from this repo. TheMakefile
has a variable that points to the latest version of this image, calledDOCKER_IMAGE_DEB
. This image is used during the deploy stage to generate the Debian installer for Appsody. - The
rpmbuilder
Docker image, which builds the RPM installer for Appsody. Currently, we use the image provided byalectolytic
, and we point to it through theMakefile
env varDOCKER_IMAGE_RPM
.
We expect the Docker images for the Debian and RPM installers to change very rarely. The Appsody controller may be released more frequently. Generally, a new release of the Controller requires a new release of the Appsody CLI.
When the Appsody CLI is released, the build process also updates the Appsody website repository and the Appsody Homebrew formula, as we mentioned earlier. The update creates a new branch in those repos, and it is expected that the maintainers create new pull requests for those branches against the master branch. Keep in mind that the Appsody CLI release is complete only when those PRs are merged.
Follow this process to create a new release of the Appsody CLI.
- Run
make build-docs
which will generatebuild/cli-commands.md
- Preview the
build/cli-commands.md
file to ensure it reads well and the formatting looks correct. To preview in VS Code: open the file and doshift-command-v
The Appsody CLI is made available by creating a tagged GitHub release
- If there is a new dependent controller, a Pull Request with the
CONTROLLER_VERSION
changes to theMakefile
needs to be created and merged before continuing - Navigate to https://github.com/appsody/appsody/releases
- Click Draft a new release
- Ensure the target branch is master
- Define a tag in the format of x.y.z (example: 0.2.4). Use the tag also for the title.
- Describe the release with your release notes, including a list of the features added by the release, a list of the major issues that are resolved by the release, caveats, known issues.
- To see a comparison between master and the last release, navigate to https://github.com/appsody/appsody/compare/0.0.0...master replacing 0.0.0 with the last release.
- Check the box for This is a pre-release
- Click Publish release
- Watch the Travis build for the release and ensure it passes. The build will include the
deploy
stage of the build process as defined in.travis.yml
. Thedeploy
stage, if successful, will produce the following results:- The release page will be populated with the build artifacts (see next step)
- A new branch will be created in the homebrew-appsody repo (further steps below)
- A new branch will be created in the website repo (further steps below)
- Check the release artifacts to ensure these all exist (again, x.y.z indicates the release - for example 0.2.4):
- appsody-x.y.z-1.x86_64.rpm
- appsody-x.y.z-darwin-amd64.tar.gz
- appsody-x.y.z-linux-amd64.tar.gz
- appsody-x.y.z-windows.tar.gz
- appsody-homebrew-x.y.z.tar.gz
- appsody.rb
- appsody_x.y.z_amd64.deb
- Edit the release and uncheck This is a pre-relsease then click Update relsease
- Go to the appsody/homebrew-appsody repo and create a PR for the new Travis build branch.
- Review and merge the PR.
- Go to the appsody/website repo and create a PR for the new Travis build branch.
- Review and merge the PR.
We plan to release the Appsody CLI at the end of each sprint - approximately every two weeks.