Java-buildpack: 使用 Java Buildpack 推送失败

@nebhale - 也许这是您最近提交的结果？

我有同样的问题：

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.

我尝试了 v4.16.1 并且有效。

也许标签名称release总是指向最新版本的标签？

由 af2e9b6 解决

感谢@nebhale 的快速回复！

我并不是说粗鲁，但这是过去几天中第二次推送到 master 破坏了我们的部署。 有没有更好的流程？ 我们的团队目前正在我们的管道中直接指定https://github.com/cloudfoundry/java-buildpack.git buildpack，这显然会导致问题。 我能找到的另一个选项是指定一个标签，例如https://github.com/cloudfoundry/java-buildpack.git#v4.16.1 ，但是管理我们所有项目和管道的版本控制的责任就落在了我的团队身上。 我相信@corneil有最好的解决方案，通过指定一个可以指向最新稳定版本的release标签。 你怎么认为？

master一直是一个活跃的开发分支，过去多次被破解。 从来没有鼓励在生产情况下依赖它，我们也不会采取任何预防措施来保持它的稳定。 使用诸如release标签之类的可变标签是一种反模式，因为它破坏了构建的可重复性（使用master另一个失败）。 鉴于 Cloud Foundry 中 buildpack 的主要用途是使用cf create-buildpack/update-buildpack固定发布版本，我们无意创建超出标记稳定版本的现有策略的任何内容。

我们的项目在 IBM Bluemix 中，默认的 java 构建包是 WebSphere Liberty Profile，因此我们必须明确指定构建包。

开发人员维护其清单或部署脚本的建议是什么？

• 使用https://github.com/cloudfoundry/java-buildpack.git并希望获得最好的结果？
• 使用https://github.com/cloudfoundry/java-buildpack.git#v4.16.1并以某种方式确定何时使用新版本？

我建议#release或#v4.x提供一种安全的权衡，对社区的影响最小。
如果你想要重现性，那么使用像#v4.16.1这样的显式版本

显然，需要对发布过程进行更改以支持这一点。

我同意@corneil。 我的想法是，希望在构建过程中具有重现性的消费者已经不得不直接指定一个标签。 公开release标签将增加灵活性，让愿意为了稳定性而牺牲可重复性的团队可以选择这样做。