Where do the buildpacks go? Issues with buildpacks

Egle

unread,

Mar 26, 2014, 5:48:48 PM3/26/14

to vcap...@cloudfoundry.org

Ferran Rodenas

unread,

Mar 26, 2014, 6:23:42 PM3/26/14

to vcap...@cloudfoundry.org

Egle, buildpacks are not pushed. You can either:

1) Push an app and set the buildpack you want to use for this app: cf push APP -b [BUILDPACK_NAME|BUILDPACK_URL]

2) Upload a buildpack (only using one of the latest cf-releases): cf create-buildpack BUILDPACK_NAME BUILDPACK_ZIP_FILE BUILDPACK_POSITION. Then the detect buildpack mechanism will determine whether or not to apply the buildpack when you push an app.

- Ferdy

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

James Bayer

unread,

Mar 27, 2014, 7:59:48 AM3/27/14

to vcap...@cloudfoundry.org

you can upload buildpacks with the cf v6 buildpack commands. help topics should be available for each one. there is a video here for Pivotal CF 1.1, but it is the same approach should apply with cf-release versions v15x something and higher [1].

BUILDPACKS:
   buildpacks                         List all buildpacks
   create-buildpack                   Create a buildpack
   update-buildpack                   Update a buildpack
   delete-buildpack                   Delete a buildpack

[1] https://www.youtube.com/watch?v=4khVIYpjnRQ&feature=youtu.be

--

Thank you,

James Bayer

Egle

unread,

Mar 27, 2014, 4:24:52 PM3/27/14

to vcap...@cloudfoundry.org

Thank you Ferdy and James, I was confused by the documentation at the buildpacks, it has examples like this:

cf push -b https://github.com/cloudfoundry/java-buildpack

https://github.com/cloudfoundry/java-buildpack

Thank you again,

Egle

Cornelia Davis

unread,

Mar 27, 2014, 6:17:38 PM3/27/14

to vcap...@cloudfoundry.org

Egle,

That is not pushing a buildpack - it is pushing an app and designating that buildpack as the one to be used.

Cornelia

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

Ben Hale

unread,

Mar 28, 2014, 6:52:08 AM3/28/14

to vcap...@cloudfoundry.org

That is not pushing a buildpack - it is pushing an app and designating that buildpack as the one to be used.

Well, that's certainly not obvious using that particular syntax. The example assumes the use of a manifest which is pretty alien to most novice Cloud Foundry users. Clearly the example is mine and needs ot be a bit more verbose for understandability (it should probably be cf push <APP-NAME> -p <ARTIFACT> -b https://github.com/cloudfoundry/java-buildpack.git). Alas the danger of using Cloud Foundry heavily every day and forgetting what it's like for most users.

@Egle, can you help me out by letting me know where you've run into that example? I'll do a search to get as many of them as I can, but I want to make sure that I've covered the place that you found it. Thanks.

-Ben Hale

Cloud Foundry Java Experience

Egle

unread,

Mar 28, 2014, 9:54:47 AM3/28/14

to vcap...@cloudfoundry.org

Thank you Ben, the example syntax was my problem. I think you already fixed the example where I found it,

https://github.com/cloudfoundry/java-buildpack/blob/master/README.md

Do I need to specify buildpack if I am pushing a java app? It appears that java buildpack is by default in all installations of Cloud Foundry, or am I wrong?

Thank you,

Egle

Ben Hale

unread,

Mar 28, 2014, 10:08:39 AM3/28/14

to vcap...@cloudfoundry.org

Thank you Ben, the example syntax was my problem. I think you already fixed the example where I found it,

https://github.com/cloudfoundry/java-buildpack/blob/master/README.md

Yup, I've had a pretty productive morning. :)

Do I need to specify buildpack if I am pushing a java app? It appears that java buildpack is by default in all installations of Cloud Foundry, or am I wrong?

You are correct that you do not need to specify the buildpack when pushing a Java application. The version that's built in to Cloud Foundry is kept quite stable, but that means that recently added fixes and additional functionality may not be available. If you're keen on on running the bleeding edge, you can specify the buildpack to take directly out of master (or any other branch, tag, or commit). To give you an idea idea of what you'd gain if you used the latest version:

Oracle JRE support
Support for the latest version of Spring Boot
Tomcat logging directed to Loggergator
Support for Ratpack (Groovy application framework)
Classpath support for Groovy applications
Redis-based Session Replication
Improved Spring Insight support
Miscellaneous dependency upgrades (e.g. New Relic, Tomcat, etc.)

Jan Dubois

unread,

Mar 28, 2014, 3:10:53 PM3/28/14

to vcap-dev

On Fri, Mar 28, 2014 at 7:08 AM, Ben Hale <bh...@gopivotal.com> wrote:
> If you're keen on on running the bleeding edge, you can specify the
> buildpack to take directly out of master (or any other branch, tag, or
> commit).

Actually, in CF you can only specify a branch, but not a tag or commit:

https://github.com/cloudfoundry/dea_ng/blob/master/buildpacks/lib/git.rb

I did point out in a PR that Heroku allows you to use any commit id in
a buildpack URL:

https://github.com/cloudfoundry/dea_ng/pull/54

and provided a trivial patch to implement this:

https://github.com/cloudfoundry/dea_ng/commit/273a2b85e9b031bce967d0c747ffcbaa3213cc2b

But somehow it was decided that being able to do a shallow clone was
more important than being able to specify a tag.

I still feel this is misguided premature optimization for an uncommon
use case. How often to you specify a branch, so why not accept the
cost of a deep clone in that case?

Note also that the error you get when you specify a tag is easy to
miss, e.g. using
https://github.com/cloudfoundry/java-buildpack.git#v2.0 as the
buildpack URL:

| Cloning into '/tmp/buildpacks/java-buildpack'...
| warning: Remote branch v2.0 not found in upstream origin, using HEAD instead

and then staging proceeds normally using master instead of v2.0...

Cheers,
-Jan

Jan Dubois

unread,

Mar 28, 2014, 3:30:39 PM3/28/14

to vcap-dev

On Fri, Mar 28, 2014 at 12:10 PM, Jan Dubois <ja...@activestate.com> wrote:
>
> Actually, in CF you can only specify a branch, but not a tag or commit:
>
> https://github.com/cloudfoundry/dea_ng/blob/master/buildpacks/lib/git.rb

After some more testing I noticed this depends on the git version
inside the container. :(

Running this command:

$ git clone --depth 1 -b v2.0 --recursive
https://github.com/cloudfoundry/java-buildpack.git

With git 1.7.9.5 prints:

| warning: Remote branch v2.0 not found in upstream origin, using HEAD instead

but still returns an exit code of 0, so the error handling in

https://github.com/cloudfoundry/dea_ng/blob/master/buildpacks/lib/git.rb#L20

is not executed. However, using git 1.9.1 the same command prints:

| Note: checking out 'b3f72903a6ff2728f1c4ab792ceb5fb093debf8d'.

and exit code is again 0, but in this case git actually made a shallow
clone of the tag.

So with a recent enough version of git everything works correctly.
Sorry for my negative/alarmist previous message.

Cheers,
-Jan

Reply all

Reply to author

Forward