Closed tcdowney closed 6 years ago
We have created an issue in Pivotal Tracker to manage this:
https://www.pivotaltracker.com/story/show/160470027
The labels on this github issue will be updated when the story is started.
@sclevine
When those buildpacks exist for the default stack in the environment (in this case cflinuxfs2) it will actually stage with the cflinuxfs2 buildpacks.
@tcdowney can you add the logs of this scenario? We are seeing this:
$ cf p ruby_go -b go_buildpack -b ruby_buildpack -s cflinuxfs3
Go Buildpack version 1.8.26
-----> Installing godep 80
Download [https://buildpacks.cloudfoundry.org/dependencies/godep/godep-v80-linux-x64-cflinuxfs3-b60ac947.tgz]
-----> Installing glide 0.13.1
Download [https://buildpacks.cloudfoundry.org/dependencies/glide/glide-v0.13.1-linux-x64-cflinuxfs3-6f19a57c.tgz]
-----> Installing dep 0.5.0
Download [https://buildpacks.cloudfoundry.org/dependencies/dep/dep-v0.5.0-linux-x64-cflinuxfs3-f9b0e8ec.tgz]
-----> Installing go 1.8.7
Download [https://buildpacks.cloudfoundry.org/dependencies/go/go1.8.7.linux-amd64-cflinuxfs3-db742637.tar.gz]
-----> Ruby Buildpack version 1.7.22
-----> Supplying Ruby
-----> Installing ruby 2.3.7
Download [https://buildpacks.cloudfoundry.org/dependencies/ruby/ruby-2.3.7-linux-x64-cflinuxfs3-a72dc47f.tgz]
...
With cflinuxfs3 in the URLs: Download [https://buildpacks.cloudfoundry.org/dependencies/ruby/ruby-2.3.7-linux-x64-**cflinuxfs3**-a72dc47f.tgz]
@tylerphelan I think I accidentally got my app in a weird state when I noticed that happen and got the app's stack set back to cflinuxfs2
. As long as the CLI successfully sets the stack
on the app itself it will behave as you described above because of this fallback:
Please fill out the issue checklist below and provide ALL the requested information.
CF_TRACE=1
to help debug the issue.Describe the bug and the command you saw an issue with This behavior was reported to CAPI last week. A user was trying to push an app using multiple buildpacks with a specific stack.
Example:
~When those buildpacks exist for the default stack in the environment (in this case
cflinuxfs2
) it will actually stage with thecflinuxfs2
buildpacks.~ (This was wrong, my app got in a weird state) If there are nocflinuxfs2
buildpacks that match the requested names it will fail with a validation error.See CAPI #160325184 for more information.
What happened To get this to fail in a more obvious way, I first had to remove/rename the
cflinuxfs2
Ruby buildpack:cf curl /v2/buildpacks?q:name=ruby_buildpack
"stack": "cflinuxfs2"
and note its guidcf curl -X PUT /v2/buildpacks/<guid> -d '{"name": "ruby_buildpack_backup"}'
My installed buildpacks now looked like this:
Then I attempted to push an app:
The push failed and said it was not able to find the
ruby_buildpack
I asked for.The actual API request that CLI made omitted the stack so CC was falling back to the system default stack.
Expected behavior I would have expected it to find and use the
cflinuxfs3
versions of the specified buildpacks to stage.I was able to get it to work with a manual curl like this:
To Reproduce You can pretty much follow the steps above, but to reiterate them (copy pasta'd from CAPI #160325184):
cflinuxfs3
stack andcflinuxfs3
-aware buildpacks: add-cflinuxfs3.yml.cflinuxfs2
builpacks for which there is a correspondingcflinuxfs3
buildpackcf curl /v2/buildpacks?q:name=ruby_buildpack
"stack": "cflinuxfs2"
and note its guidcf curl -X PUT /v2/buildpacks/<guid> -d '{"name": "ruby_buildpack_backup"}'
ruby_buildpack
) and stackcflinuxfs3
:cf push bug -b ruby_buildpack -b php_buildpack -s cflinuxfs3
Buildpack "ruby_buildpack" must be an existing admin buildpack or a valid git URI
See CAPI #160325184 for more information on repro steps.
Provide more context
6.39.0+607d4f8be.2018-09-11
1.68.0