Java-buildpack: Empujar con Java Buildpack fallando

@nebhale : ¿tal vez este sea el resultado de las recientes confirmaciones que realizó?

Tuve el mismo 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.

Probé v4.16.1 y funcionó.

¿Quizás un nombre de etiqueta release que siempre apunte a la etiqueta con la última versión?

Resuelto por af2e9b6

¡Gracias por la rápida respuesta @nebhale!

No quiero ser grosero, pero esta es la segunda vez en los últimos dos días que un esfuerzo para dominar ha roto nuestro despliegue. ¿Existe un mejor proceso para esto? Nuestro equipo está especificando actualmente el paquete https://github.com/cloudfoundry/java-buildpack.git construcción https://github.com/cloudfoundry/java-buildpack.git#v4.16.1 , pero luego la responsabilidad de administrar el control de versiones para todos nuestros proyectos y canalizaciones recae en mi equipo. Creo que @corneil tiene la mejor solución al especificar una etiqueta release que puede apuntar a la última versión estable. ¿Cuáles son tus pensamientos?

master siempre ha sido una rama de desarrollo activa y se ha roto muchas veces en el pasado. Depender de él en una situación de producción nunca se ha fomentado y no tomamos ninguna precaución para mantenerlo estable. El uso de etiquetas mutables como release es un anti-patrón porque rompe la reproducibilidad de la construcción (otra falla de usar master ). Dado que el uso principal de paquetes de compilación en Cloud Foundry es con versiones de lanzamiento fijas usando cf create-buildpack/update-buildpack , no tenemos la intención de crear nada más allá de la estrategia existente de lanzamientos estables etiquetados.

Nuestro proyecto está en IBM Bluemix y el paquete de compilación java predeterminado es WebSphere Liberty Profile, por lo que tenemos que especificar el paquete de compilación explícitamente.

¿Cuál sería la sugerencia para que los desarrolladores mantengan sus manifiestos o scripts de implementación?

• Utilice https://github.com/cloudfoundry/java-buildpack.git y espere lo mejor?
• ¿Usa https://github.com/cloudfoundry/java-buildpack.git#v4.16.1 y de alguna manera determina cuándo usa una nueva versión?

Sugeriría que #release o #v4.x brinden una compensación segura con el menor impacto en la comunidad.
Si desea reproducibilidad, utilice una versión explícita como #v4.16.1

Obviamente, se necesitan cambios en el proceso de lanzamiento para respaldar esto.

Estoy de acuerdo con @corneil. Mi proceso de pensamiento es que los consumidores que esperan reproducibilidad en los procesos de compilación ya tienen que especificar directamente una etiqueta. Exponer una etiqueta release agregará flexibilidad, dando a los equipos que están dispuestos a sacrificar la reproducibilidad por la estabilidad la opción de hacerlo.