Java-buildpack: Échec de la poussée avec Java Buildpack

@nebhale - est-ce peut-être le résultat des récents engagements que vous avez pris ?

J'ai eu le même problème :

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.

J'ai essayé la v4.16.1 et cela a fonctionné.

Peut-être un nom de balise release qui pointe toujours vers la dernière balise versionnée ?

Résolu par af2e9b6

Merci pour la réponse rapide @nebhale !

Je ne veux pas être impoli, mais c'est la deuxième fois au cours des deux derniers jours qu'une poussée vers la maîtrise interrompt notre déploiement. Existe-t-il un meilleur processus pour cela? Notre équipe spécifie actuellement le https://github.com/cloudfoundry/java-buildpack.git buildpack directement dans notre pipeline, ce qui entraîne évidemment des problèmes. L'autre option que je peux trouver est de spécifier une balise telle que https://github.com/cloudfoundry/java-buildpack.git#v4.16.1 , mais la responsabilité de gérer la gestion des versions pour tous nos projets et pipelines incombe alors à mon équipe. Je pense que @corneil a la meilleure solution, en spécifiant une balise release qui peut pointer vers la dernière version stable. Quelles sont vos pensées?

master a toujours été une branche de développement active, et a été cassée à plusieurs reprises dans le passé. En dépendre dans une situation de production n'a jamais été encouragé et nous ne prenons aucune précaution pour le maintenir stable. L'utilisation de balises mutables telles qu'une balise release est un anti-modèle car elle casse la reproductibilité de la construction (un autre échec de l'utilisation de master ). Étant donné que l'utilisation principale des buildpacks dans Cloud Foundry concerne les versions publiées fixes utilisant cf create-buildpack/update-buildpack , nous n'avons aucune intention de créer quoi que ce soit au-delà de la stratégie existante des versions stables balisées.

Notre projet est dans IBM Bluemix et le pack de construction Java par défaut est WebSphere Liberty Profile, nous devons donc spécifier explicitement le pack de construction.

Quelle serait la suggestion pour les développeurs de maintenir leurs manifestes ou leurs scripts de déploiement ?

• Utilisez https://github.com/cloudfoundry/java-buildpack.git et espérez le meilleur ?
• Utilisez https://github.com/cloudfoundry/java-buildpack.git#v4.16.1 et déterminez d'une manière ou d'une autre quand vous utilisez une nouvelle version ?

Je dirais que #release ou #v4.x offre un compromis sûr avec le plus faible impact sur la communauté.
Si vous voulez de la reproductibilité, utilisez une version explicite comme #v4.16.1

De toute évidence, des changements sont nécessaires dans le processus de publication pour prendre en charge cela.

Je suis d'accord avec @corneil. Mon processus de pensée est que les consommateurs qui s'attendent à une reproductibilité dans les processus de construction doivent déjà spécifier directement une balise. L'exposition d'une balise release ajoutera de la flexibilité, donnant aux équipes qui sont prêtes à sacrifier la reproductibilité pour la stabilité la possibilité de le faire.