Closed youngm closed 11 years ago
So, I'm aware that another way I could solve this is to create manifests for all of the apps in the asset project that need a build pack. However, the buildpack that we don't include as standard in our DEAs is a ruby build pack. Since most of the tests use ruby it would be difficult to create and maintain manifests for all the ruby project assets.
@youngm — Thanks for this pull request! We understand the value of being able to run the yeti tests in different environments. However, in this case we would like to ensure that the use of a gem from a git://
URI continues to work in our https://run.pivotal.io environment, especially from GitHub. We've had cases before where a planned firewall change for our AWS deployment would have stopped this from working and this test prevented the regression.
What if instead a new test was added specifically for the http://
gems and it is possible to omit the git://
test by using a RSpec tag?
@xoebus / @ryantang
Makes sense. Thanks for considering it. I'll go ahead and close this PR and open a new one if I decide to add an http:// test.
I couldn't get the git:// urls to work in my firewalled enterprise that requires an http proxy. This PR changes the git:// url to http so that it can work through a proxy.
This change is testing essentially the same thing as the git:// use case but with http instead. Arguably a super set of the git:// test.
This change updates the ruby spec to look for an http:// url instead of git://
The assets PR can be found here: https://github.com/cloudfoundry/vcap-test-assets/pull/6