Re: Best practices on bosh release distribution


Gwenn Etourneau
 

If you OpenSource your bosh-release you can ask to be added to
https://github.com/cloudfoundry-community/ and you will be able to ask for
the community s3 bucket to put your final release and maybe be added to the
bosh.io 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)sas.com>
wrote:

Hi,



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?



Thanks,

Sumanth

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh

Join {cf-bosh@lists.cloudfoundry.org to automatically receive all group messages.