Java-buildpack: Push com falha do Java Buildpack

@nebhale - talvez isso seja resultado dos commits recentes que você fez?

Eu tive o mesmo problema:

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.

Tentei a v4.16.1 e funcionou.

Talvez um nome de tag release que sempre aponta para a tag com a versão mais recente?

Resolvido por af2e9b6

Obrigado pela resposta rápida @nebhale!

Não quero ser rude, mas esta é a segunda vez nos últimos dias que um push para dominar interrompe nossa implantação. Existe um processo melhor para isso? Nossa equipe está especificando o buildpack https://github.com/cloudfoundry/java-buildpack.git diretamente em nosso pipeline, o que obviamente está causando problemas. A outra opção que posso encontrar é especificar uma tag como https://github.com/cloudfoundry/java-buildpack.git#v4.16.1 , mas a responsabilidade de gerenciar o controle de versão para todos os nossos projetos e pipelines é da minha equipe. Acredito que @corneil tenha a melhor solução, especificando uma tag release que pode apontar para a versão estável mais recente. Quais são seus pensamentos?

master sempre foi um branch de desenvolvimento ativo e foi quebrado várias vezes no passado. Depender dele em uma situação de produção nunca foi encorajado e não tomamos nenhum cuidado para mantê-lo estável. O uso de tags mutáveis, como release é um anti-padrão porque quebra a reprodutibilidade do build (outra falha no uso de master ). Dado que o uso principal de buildpacks no Cloud Foundry é com versões lançadas fixas usando cf create-buildpack/update-buildpack , não temos intenção de criar nada além da estratégia existente de lançamentos estáveis ​​marcados.

Nosso projeto está no IBM Bluemix e o buildpack java padrão é o WebSphere Liberty Profile, portanto, temos que especificar o build pack explicitamente.

Qual seria a sugestão para os desenvolvedores manterem seus manifestos ou scripts de implantação?

• Use https://github.com/cloudfoundry/java-buildpack.git e torce pelo melhor?
• Use https://github.com/cloudfoundry/java-buildpack.git#v4.16.1 e, de alguma forma, determine quando usar uma nova versão?

Eu sugeriria que #release ou #v4.x fornecem uma troca segura com o menor impacto na comunidade.
Se você quiser reprodutibilidade, use uma versão explícita como #v4.16.1

Obviamente, são necessárias mudanças no processo de lançamento para dar suporte a isso.

Eu concordo com @corneil. Meu processo de pensamento é que os consumidores que esperam reprodutibilidade nos processos de compilação já precisam especificar uma tag diretamente. Expor uma tag release adicionará flexibilidade, dando às equipes que estão dispostas a sacrificar a reprodutibilidade pela estabilidade a opção de fazê-lo.