Java-buildpack: Push with Java Buildpack Failing

@nebhale - perhaps this is a result of the recent commits you made?

I had same issue:

Java Buildpack 9c46802 | https://github.com/cloudfoundry/java-buildpack.git#9c46802
No start command specified by buildpack or via Procfile.
App will not start unless a command is provided at runtime.

I tried v4.16.1 and it worked.

Maybe a tag name release that always point to latest versioned tag?

Resolved by af2e9b6

Thanks for the speedy response @nebhale!

I don't mean to be rude, but this is the second time in the past couple days that a push to master has broken our deployment. Is there a better process for this? Our team is currently specifying the https://github.com/cloudfoundry/java-buildpack.git buildpack directly in our pipeline, which is obviously leading to issues. The other option I can find is to specify a tag such as https://github.com/cloudfoundry/java-buildpack.git#v4.16.1, but then the responsibility of managing versioning for all our projects and pipelines falls on my team. I believe @corneil has the best solution, by specifying a release tag that can point to the latest stable release. What are your thoughts?

master has always been an active development branch, and has been broken at many times in the past. Depending on it in a production situation has never been encouraged and we don't make take any precautions to keep it stable. Use of mutable tags such as a release tag is an anti-pattern because it breaks build reproducibility (another failing of using master). Given that the primary use of buildpacks in Cloud Foundry is with fixed released versions using cf create-buildpack/update-buildpack, we have no intention to create anything beyond the existing strategy of tagged stable releases.

Our project is in IBM Bluemix and the default java buildpack is WebSphere Liberty Profile, so we have to specify the build pack explicitly.

What would be the suggestion for developers to maintain their manifests or deployment scripts?

• Use https://github.com/cloudfoundry/java-buildpack.git and hope for the best?
• Use https://github.com/cloudfoundry/java-buildpack.git#v4.16.1 and somehow determine when you use a new version?

I would suggest that #release or #v4.x provides a safe trade-off with the lowest impact on the community.
If you want reproducibility then use an explicit version like #v4.16.1

Obviously, changes are needed to the release process to support this.

I agree with @corneil. My thought process is that consumers who are expecting reproducibility in build processes are already having to directly specify a tag. Exposing a release tag will add flexibility, giving teams who are willing to sacrifice reproducibility for stability the option to do so.