Edit:
Saya tidak lagi menggunakan pendekatan ini, silakan gunakan salah satu jawaban lain.
Pembaruan: apa yang akhirnya saya lakukan, untuk kasus khusus kami: (jawaban di atas sangat bagus - terima kasih!)
Karena server build kami tidak ada di internet, kami memiliki skrip untuk menerbitkan status build ke cabang gh-pages di github.
- Mulai membangun prangko gagal
- Akhir membangun prangko sukses
- Proyek berjalan setelah proyek utama untuk mempublikasikan hasil -> status bangunan, dokumen API, laporan pengujian dan cakupan pengujian.
GitHub melakukan cache gambar, jadi kami membuat file .htaccess, yang menginstruksikan batas waktu cache singkat untuk gambar status-bangunan.
Letakkan ini di direktori dengan gambar build-status:
ExpiresByType image/png "access plus 2 minutes"
Ini skrip pembuatannya. Target yang menerbitkan ke gh-pages adalah '--publish.site.dry.run'
Dengan kurang dari 400 baris konfigurasi, kami memiliki:
- Kompilasi cek
- tes unit & integrasi
- Laporan Uji
- Laporan Cakupan Kode
- API Documents
- Penerbitan ke Github
. . dan skrip ini dapat dijalankan di dalam atau di luar Jenkins, sehingga:
- Pengembang dapat menjalankan skrip ini sebelum melakukan, mengurangi kemungkinan bangunan rusak yang memengaruhi orang lain.
- Kegagalan mudah direproduksi secara lokal.
Hasil:
Halaman utama proyek memiliki status build, diperbarui setelah setiap build, bersama dengan API Documents terbaru, hasil pengujian dan cakupan pengujian.