Java-buildpack: Push mit Java Buildpack fehlgeschlagen

@nebhale - vielleicht ist dies ein Ergebnis der letzten Commits, die Sie gemacht haben?

Ich hatte das gleiche Problem:

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.

Ich habe v4.16.1 ausprobiert und es hat funktioniert.

Vielleicht ein Tag-Name release , der immer auf die neueste Version des Tags verweist?

Gelöst von af2e9b6

Danke für die schnelle Antwort @nebhale!

Ich möchte nicht unhöflich sein, aber dies ist das zweite Mal in den letzten Tagen, dass ein Push-to-Master unseren Einsatz unterbrach. Gibt es dafür ein besseres Verfahren? Unser Team spezifiziert derzeit das https://github.com/cloudfoundry/java-buildpack.git Buildpack direkt in unserer Pipeline, was offensichtlich zu Problemen führt. Die andere Option, die ich finden kann, besteht darin, ein Tag wie https://github.com/cloudfoundry/java-buildpack.git#v4.16.1 anzugeben, aber dann liegt die Verantwortung für die Verwaltung der Versionsverwaltung für alle unsere Projekte und Pipelines bei meinem Team. Ich glaube, @corneil hat die beste Lösung, indem es ein release Tag angibt, das auf die neueste stabile Version verweisen kann. Was sind deine Gedanken?

master schon immer ein aktiver Entwicklungszweig und wurde in der Vergangenheit oft abgebrochen. Abhängig davon in einer Produktionssituation wurde nie ermutigt und wir treffen keine Vorkehrungen, um es stabil zu halten. Die Verwendung von veränderlichen Tags wie einem release Tag ist ein Anti-Pattern, da es die Build-Reproduzierbarkeit unterbricht (ein weiterer Fehler bei der Verwendung von master ). Da die primäre Verwendung von Buildpacks in Cloud Foundry mit fixierten veröffentlichten Versionen mit cf create-buildpack/update-buildpack , haben wir nicht die Absicht, etwas über die bestehende Strategie der getaggten stabilen Releases hinaus zu entwickeln.

Unser Projekt befindet sich in IBM Bluemix und das standardmäßige Java-Buildpack ist WebSphere Liberty Profile, daher müssen wir das Buildpack explizit angeben.

Was wäre der Vorschlag für Entwickler, ihre Manifeste oder Bereitstellungsskripts beizubehalten?

• Verwenden Sie https://github.com/cloudfoundry/java-buildpack.git und hoffen Sie auf das Beste?
• Verwenden Sie https://github.com/cloudfoundry/java-buildpack.git#v4.16.1 und bestimmen Sie irgendwie, wann Sie eine neue Version verwenden?

Ich würde vorschlagen, dass #release oder #v4.x einen sicheren Kompromiss mit den geringsten Auswirkungen auf die Community bietet.
Wenn Sie Reproduzierbarkeit wünschen, verwenden Sie eine explizite Version wie #v4.16.1

Offensichtlich sind Änderungen am Freigabeprozess erforderlich, um dies zu unterstützen.

Ich stimme @corneil zu. Mein Denkprozess ist, dass Verbraucher, die Reproduzierbarkeit in Build-Prozessen erwarten, bereits ein Tag direkt angeben müssen. Das Freilegen eines release Tags erhöht die Flexibilität und gibt Teams, die bereit sind, Reproduzierbarkeit für Stabilität zu opfern, die Möglichkeit, dies zu tun.