Java-buildpack: Dorong dengan Java Buildpack Gagal

@nebhale - mungkin ini adalah hasil dari komitmen baru-baru ini yang Anda buat?

Saya memiliki masalah yang sama:

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.

Saya mencoba v4.16.1 dan berhasil.

Mungkin nama tag release yang selalu mengarah ke tag versi terbaru?

Diselesaikan oleh af2e9b6

Terima kasih atas respons cepatnya @nebhale!

Saya tidak bermaksud kasar, tetapi ini adalah kedua kalinya dalam beberapa hari terakhir dorongan untuk menguasai telah merusak penerapan kami. Apakah ada proses yang lebih baik untuk ini? Tim kami saat ini sedang menentukan buildpack https://github.com/cloudfoundry/java-buildpack.git langsung di pipeline kami, yang jelas menyebabkan masalah. Opsi lain yang dapat saya temukan adalah menentukan tag seperti https://github.com/cloudfoundry/java-buildpack.git#v4.16.1 , tetapi kemudian tanggung jawab mengelola pembuatan versi untuk semua proyek dan saluran kami berada di tim saya. Saya percaya @corneil memiliki solusi terbaik, dengan menentukan tag release yang dapat menunjukkan rilis stabil terbaru. Apa yang Anda pikirkan?

master selalu menjadi cabang pengembangan yang aktif, dan telah rusak berkali-kali di masa lalu. Bergantung padanya dalam situasi produksi tidak pernah didorong dan kami tidak mengambil tindakan pencegahan apa pun untuk membuatnya tetap stabil. Penggunaan tag yang dapat diubah seperti tag release adalah anti-pola karena merusak reproduktifitas build (kegagalan lain dalam menggunakan master ). Mengingat bahwa penggunaan utama buildpack di Cloud Foundry adalah dengan versi rilis tetap menggunakan cf create-buildpack/update-buildpack , kami tidak berniat untuk membuat apa pun di luar strategi rilis stabil yang diberi tag.

Proyek kami ada di IBM Bluemix dan java buildpack default adalah WebSphere Liberty Profile, jadi kami harus menentukan paket build secara eksplisit.

Apa saran bagi pengembang untuk mempertahankan manifes atau skrip penerapan mereka?

• Gunakan https://github.com/cloudfoundry/java-buildpack.git dan berharap yang terbaik?
• Gunakan https://github.com/cloudfoundry/java-buildpack.git#v4.16.1 dan entah bagaimana menentukan kapan Anda menggunakan versi baru?

Saya menyarankan bahwa #release atau #v4.x memberikan pertukaran yang aman dengan dampak terendah pada komunitas.
Jika Anda ingin reproduktifitas maka gunakan versi eksplisit seperti #v4.16.1

Jelas, perubahan diperlukan pada proses rilis untuk mendukung ini.

Saya setuju dengan @corneil. Proses pemikiran saya adalah bahwa konsumen yang mengharapkan reproduktifitas dalam proses pembuatan harus secara langsung menentukan tag. Mengekspos tag release akan menambah fleksibilitas, memberi tim yang bersedia mengorbankan reproduktifitas demi stabilitas opsi untuk melakukannya.