Updated microbosh.rb to allow update if the deployment exists, or create a new one if it does not exist.

[gitbisect]

Here is the new syntax for bosh micro deploy:

micro deploy [] [--update] [--update-if-exists]
Deploy a micro BOSH instance to the currently selected deployment
--update update existing instance
--update-if-exists create new or update existing instance

When I ran bosh-bootstrap deploy on an existing instance it fails asking if I meant to update. The newer syntax allows for --update-if-exists in addition to --update and it works very well. I tested it.

[drnic]

Hey mate, there's one unit test to fix up:

• https://travis-ci.org/cloudfoundry-community/bosh-bootstrap/jobs/13073564#L107

[drnic]

Thanks a lot for the PR on allowing updates!

[gitbisect]

Updated test to pass with the new code.
https://travis-ci.org/lookitup4me/bosh-bootstrap/jobs/13105712

[drnic]

Yeah can you go back to the commit before the .travis.yml change and force push it to your branch?

Probably something like the following:

git revert HEAD~1 --hard
git push lookitup4me master -f

ProTip: create new branches when doing PRs - makes it funner and easier to have parallel branches/PRs and keep master in sync with the upstream repo's master. That's my workflow if its helpful.

[gitbisect]

Hi Dr Nic

Thanks for the tip. Since my repo was pretty new, I killed it and
re-forked. I created a branch called allow-updates, made the travis job
pass and created a PR.

I have a question for you if you dont mind. I thought I would update the
.travis.yml file so that it would not bug you every time a build in my fork
failed. But if I update the email address in my fork, and I put it in the
master branch - I think it will always conflict when I pull the upstream.
But if I change it only in a branch that I build, then when I create the
pull request, it will come to mess up your master. So what is the accepted
way to have travis send me email without disturbing you or creating
conflicts?

Thanks. Please pardon my ignorance in the ways of the opensource.
John

On Sun, Oct 27, 2013 at 3:00 PM, Dr Nic Williams
notifications@github.comwrote:

Yeah can you go back to the commit before the .travis.yml change and force
push it to your branch?

Probably something like the following:

git revert HEAD~1 --hard
git push lookitup4me master -f

ProTip: create new branches when doing PRs - makes it funner and easier to
have parallel branches/PRs and keep master in sync with the upstream repo's
master. That's my workflow if its helpful.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/244#issuecomment-27180550
.

[drnic]

That's a good question about how diff forks can use different .travis.yml
but not include them in the PRs. Perhaps ask @TravisCI guys - they might
have some ideas.

I'm always ok with getting build notices from forks. Fun to know if someone
is trying to add features.

Nic

[gitbisect]

Okay. Thanks.

Sent from my iPhone

On Oct 28, 2013, at 7:16 AM, Dr Nic Williams notifications@github.com wrote:

That's a good question about how diff forks can use different .travis.yml
but not include them in the PRs. Perhaps ask @TravisCI guys - they might
have some ideas.

I'm always ok with getting build notices from forks. Fun to know if someone
is trying to add features.

Nic
—
Reply to this email directly or view it on GitHub.

[gitbisect]

Poms App sent you an invitation

Twitter helps you stay connected with what's happening right now and with the people and organizations you care about.

Accept invitation

https://twitter.com/i/46096df8-40fe-4046-9bb2-a136870d8a86

You can unsubscribe from receiving email notifications from Twitter at anytime. For general inquiries, please visit us at Twitter Support.
Unsubscribe: https://twitter.com/i/o?t=1&iid=ce0ce90e541e4dac9349540189b8676d&uid=0&c=IuVwbCB3dgEj8Rt3qq82PAB9jnSlLBJQmkoe63Uz2IsetQUXxrfRFJURai8DITA7xYDh8WHCKPYQRpBX5SJERYoPjQQEkw8vByNvbrISKqw%2FonXkPaKfkQ%3D%3D&nid=9+26

Need help?
https://support.twitter.com