Re: Best practices on bosh release distribution

Gwenn Etourneau

If you OpenSource your bosh-release you can ask to be added to and you will be able to ask for
the community s3 bucket to put your final release and maybe be added to the website.

Or/and you can create a tarball of the full release and distribute this
tarball and of course the documentation for the bosh deployment manifest.

create release [<manifest_file>] [--force] [--final] [--with-tarball]
[--dry-run] [--name NAME] [--version VERSION]
Create release (assumes current directory to be a release repository)
--force bypass git dirty state check
--final create final release
* --with-tarball* create release tarball
--dry-run stop before writing release manifest
--name NAME specify a custom release name
--version VERSION specify a custom version number
(ex: 1.0.0 or 1.0-beta.2+dev.10)

On Sat, Jun 6, 2015 at 12:12 AM, Sumanth Yamala <Sumanth.Yamala(a)>


I have a process which creates a bosh release -> which has all the
artifacts and use a microbosh instance to create my release. It all works
great! As I move to the next step to distribute my releases to cross
departments and external customers – what are the best practices around
this? How do we distribute bosh releases?



cf-bosh mailing list

Join { to automatically receive all group messages.