Custom "Failure" Buildpack

[Josh Ghiloni]

We've got an interesting situation I was hoping for some insight into. Our client would like developers to explicitly to always state their buildpacks (either on the CLI or in the manifest) when pushing their apps, so I've been tasked to creating a buildpack that will sit at priority one in the list of buildpacks. The buildpack should output a message to the developer, and just fails.

Currently, I've gotten the failure part working (I just return 1 at the end of the "release" script), but what I've not yet been able to do is get it to output anything. I'm using bash for this buildpack, and here are the scripts themselves (modeled after [1]):

detect:

#!/usr/bin/env bash

echo "----> Using the fail buildpack"

echo "----> If you're here, you didn't explicitly set your buildpack info."

echo "-----> This buildpack will now fail."

compile:

#!/usr/bin/env bash

echo "----> You must specify a buildpack on the command line (-b) or in your manifest.yml file"

release:

#!/usr/bin/env bash

exit 255

My question is simple. What should I do to get those echo statements to appear when you run `cf push`? Do those three scripts need to complete successfully and then just run a script that fails? 

[1] https://github.com/ryandotsmith/null-buildpack

[James Bayer]

what is the behavior you observe with CF_TRACE=true turned on with "cf push"?

--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/91777cf9-174c-49ab-858c-7724bd4249dc%40cloudfoundry.org.

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

--

Thank you,

James Bayer

[JT Archie]

Josh, when you create these scripts are you marking them as executable? Then are not sourced automatically. Your buildpack may be working for the wrong reasons.

JT

[Josh Ghiloni]

A ha! Both great ideas, that I will try out momentarily.

--

You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/d9cac8d7-5f17-44ab-b20d-b251e905057d%40cloudfoundry.org.

[Josh Ghiloni]

Thanks, JT. That is what the problem was. I am seeing one more issue, and I'm not sure if there's a way to prevent it. If I put the failure point in the release script, it tries to start the app anyway and fails because things haven't been loaded properly (using a Ruby app as a test bed for this, sure it would be similar for Java, since the JRE wouldn't be initialized). I would normally have no problem with that except it keeps retrying. If I put the failure in the compile phase, it doesn't attempt to start the app, which is good. However, whatever goes to stdout in that script gets dumped to the logs, but does NOT get output to the console, which is ... less than desirable, but livable as far as I'm concerned. 

Much rambling aside, is there a way to either force output from the compile phase to the console regardless of success (akin to a flush), or alternatively, is there a way to set an env variable or something similar so that if it fails to start in the release phase, it does not retry? I think that option 1 is more desirable.

[JT Archie]

Josh, with bash/shell scripts, when you are using `echo` it automatically flushes on execution. Admittedly, CloudFoundry CLI might not be flushing to the console fully on Staging failure because not enough output has occurred, but that is just a guess.

You are putting responsibility in a buildpack to protect the user from a defined process. Would it make more sense to provide an alternative of deployment? CloudFoundry CLI plugins can be made.

Kind Regards, JT

[Josh Ghiloni]

I've thought about that, but I don't know how well that'll integrate with our CI process that we don't really own. I talked with one of the main stakeholders this morning and he's fine with leaving things in the logs. Thanks for the great pointer on the permissions, though. Totally skipped my mind.

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/813870d7-1481-4480-a1d8-d1db6c2ad922%40cloudfoundry.org.