Java-buildpack: Отправка с отказом пакета сборки Java

@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!

Я не хочу показаться грубым, но это второй раз за последние пару дней, когда принудительное развертывание нарушило наше развертывание. Есть ли для этого лучший способ? В настоящее время наша команда указывает пакет сборки https://github.com/cloudfoundry/java-buildpack.git прямо в нашем конвейере, что, очевидно, приводит к проблемам. Другой вариант, который я могу найти, - это указать тег, например https://github.com/cloudfoundry/java-buildpack.git#v4.16.1 , но тогда ответственность за управление версиями для всех наших проектов и конвейеров ложится на мою команду. Я считаю, что у @corneil есть лучшее решение, указав тег release который может указывать на последний стабильный выпуск. Что ты думаешь?

master всегда была активной ветвью разработки и много раз ломалась в прошлом. Зависимость от этого в производственной ситуации никогда не поощрялась, и мы не принимаем никаких мер, чтобы поддерживать ее стабильность. Использование изменяемых тегов, таких как тег release является анти-шаблоном, поскольку он нарушает воспроизводимость сборки (еще один недостаток использования master ). Учитывая, что в основном пакеты сборки используются в Cloud Foundry с фиксированными выпущенными версиями с использованием 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 добавит гибкости, давая возможность командам, которые готовы пожертвовать воспроизводимостью ради стабильности, сделать это.