Libelektra: Buat Situs Web

• dokumentasi diperbaiki, sehingga terlihat bagus di situs web dan memiliki gaya yang seragam
• halaman berita/log perubahan
• stabilitas yang sama juga untuk backend
• todos di #1030 selesai

Saya pikir stabilitas registrasi tidak masalah, ini adalah tanggung jawab kami untuk tidak menghapus database.

Terima kasih atas masukan Anda!

Saya menambahkan poin Anda kecuali yang tertulis "dokumentasi _sebagian besar_ diperbaiki" dan saya mengecualikan bahwa #1030 perlu dilakukan sepenuhnya. Tentu saja akan menyenangkan untuk memilikinya, tetapi itu tidak penting. Sebagai gantinya saya menambahkan "titik masuk dokumen bagus dan sudah dibaca".

Saya menambahkan pipa penyebaran dan keamanan

Deployment melalui build seharusnya sudah berfungsi.

Terima kasih! Penerapan berhasil! Tapi tolong singkirkan sleep(s) selama penerapan. Ini menambah banyak waktu henti.

Saya menghapus sleep antara backend stop dan start, tetapi sleep lainnya harus tetap untuk alasan yang bagus:
Skrip awal menjalankan backend di latar belakang dan karena cache perlu dimuat terlebih dahulu, kami tidak dapat memastikan bahwa backend sudah dapat dijangkau (diperlukan untuk pembuatan peta situs dan kali ini akan meningkat dengan jumlah cuplikan). Tetapi tidur 60 detik tidak masalah karena versi frontend terakhir masih online dan dapat dijangkau sepanjang waktu - kami hanya mengganti file frontend tanpa menghapusnya sama sekali.

Sempurna, diselesaikan kemudian!

Saya juga menambahkan "tulis catatan rilis untuk layanan cuplikan/halaman web baru". Seharusnya bukan hal baru dan saya bisa membantu. Bisakah kami juga menyebutkan homebrew dan hal-hal lain (tidak terkait langsung dengan perangkat lunak)?

Omong-omong. apa cara termudah untuk membuat berita awal yang seharusnya belum ditampilkan di situs web?

Sebuah PR atau cabang baru harus menjadi cara termudah untuk menghindari penerbitan awal.

Bagaimana dengan tidak memiliki ekstensi file yang benar? Atau apakah Anda menggunakan setiap file dari direktori berita?

Skrip berita gagal pada nama file yang tidak sesuai, tetapi ini dapat diubah dengan mudah sehingga mengabaikannya.

Ya, alangkah baiknya jika ada cara penyiapan berita tanpa perlu tambahan cabang atau sejenisnya. Bagaimana dengan memiliki sinaks eksplisit untuk itu? (Mungkin dimulai dengan _ atau apa?) Kemudian Anda masih bisa gagal untuk entri yang salah format.

Itu gagal dengan sengaja pada nama file yang tidak cocok dengan regex tertentu, tetapi saya dapat mengubahnya menjadi peringatan, sehingga skrip berjalan. Kemudian Anda dapat menggunakan apa pun yang tidak cocok dengan ekspresi reguler, misalnya garis bawah sebagai awalan. Saya akan melakukan ini saat menyiapkan berita.

Maksud saya, kita seharusnya hanya mengizinkan konvensi yang sangat spesifik untuk persiapan berita. Akan berguna untuk gagal pada nama yang salah jika tidak.

Omong-omong. apakah Anda memeriksa: Apakah instalasi (dan pembuatan beranda) gagal ketika npm gagal?

Maksud saya, kita seharusnya hanya mengizinkan konvensi yang sangat spesifik untuk persiapan berita. Akan berguna untuk gagal pada nama yang salah jika tidak.

Tidak, sebenarnya peringatan saja sudah cukup, karena sebenarnya tidak ada masalah dengan nama file yang salah. Kami juga dapat memiliki CMakeLists.txt di sana misalnya. File yang tidak terkait tidak secara langsung berarti ada yang rusak.

Omong-omong. apakah Anda memeriksa: Apakah instalasi (dan pembuatan beranda) gagal ketika npm gagal?

Membangun beranda jelas gagal (tidak ada gerutuan atau tidak ada dependensi = tidak ada beranda), tetapi jika instalasi cmake gagal... tidak tahu. Anda memiliki masalah dengan npm di tangan pertama, jadi Anda harus tahu lebih baik?

Kami juga dapat memiliki CMakeLists.txt di sana misalnya.

Mengapa kita melakukan ini? Dan jika kita menambahkan file di sana (katakanlah README.md) saya tentu tidak ingin ada peringatan setiap saat;)

File yang tidak terkait tidak secara langsung berarti ada yang rusak.

Sebenarnya dalam kasus ini kemungkinan besar terjadi: bisa jadi salah ketik. Tapi peringatan juga harus baik-baik saja. (Ini adalah hal yang jelas jika item berita hilang.) Tetapi secara umum lebih baik jika pembangunan beranda gagal jika terjadi kesalahan. (Kemudian saya mendapatkan email bahwa beranda tidak dapat dibangun oleh jenkins)

Omong-omong. Apakah jenkins dapat mengumpulkan peringatan yang dipancarkan npm?

tetapi jika instalasi cmake gagal ... tidak tahu.

Bisa tolong coba? Cukup buat PR yang tanpa syarat mengarah ke kesalahan dan mulai membangun hp dengan frasa.

Anda memiliki masalah dengan npm di tangan pertama, jadi Anda harus tahu lebih baik?

Instalasi cmake berjalan, tetapi saya tidak melihat apa status keluar secara keseluruhan.

Mengapa kita melakukan ini? Dan jika kita menambahkan file di sana (katakanlah README.md) saya tentu tidak ingin ada peringatan setiap saat;)

Tetapi Anda menyarankan untuk mendapatkan kesalahan alih-alih peringatan ... itu tidak masuk akal. :senyum:

Bisa tolong coba? Cukup buat PR yang tanpa syarat mengarah ke kesalahan dan mulai membangun hp dengan frasa.

Apa keluaran yang Anda inginkan? Cmake itu gagal pada npm-fail? Maksud saya, akan ada pesan kesalahan yang menyatakan masalah dengan jelas, mis

npm executable was not found
npm package <xyz> not in the npm registry
...

jadi saya ragu bahwa itu adalah masalah sama sekali.

Tetapi Anda menyarankan untuk mendapatkan kesalahan alih-alih peringatan ... itu tidak masuk akal. :senyum:

Ya, kesalahan harus membatalkan semuanya dan kemudian kami menambahkan dukungan eksplisit untuk file tersebut (jika diperlukan).

Apa keluaran yang Anda inginkan? Cmake itu gagal pada npm-fail? Maksud saya, akan ada pesan kesalahan yang menyatakan masalah dengan jelas, mis

Pekerjaan membangun harus dibatalkan sebelum merusak beranda.

Mungkin juga tidak ada masalah.

Hmm, membiarkan tugas kasar gagal adalah masalah; itu berpotensi merusak beranda. Jadi kita mungkin harus menghindari itu.

Mungkin akan menjadi desain yang lebih baik untuk menjalankan tugas selama fase kompilasi (maka kegagalan tidak akan menjadi masalah), dan selama fase instalasi kami hanya akan menyalin file?

Bahkan jika Anda tidak dapat melakukannya karena perubahannya terlalu besar, setidaknya kita harus melakukannya dengan benar untuk GUI web @omnidan .

Ini adalah perubahan kecil dalam package.json dari rest-frontend dan tidak ada masalah; tetapi saya tidak dapat melakukannya hanya untuk pekerjaan pembuatan beranda kami - itu akan dilakukan untuk semua instalasi.

Tapi saya tidak melihat keuntungan sejujurnya, karena jika Anda memulai skrip pembuatan frontend, itu menghapus konten situs web dan membuatnya kembali selangkah demi selangkah melalui berbagai skrip. Dan karena skripnya sama untuk cmake dan skrip build, itu akan gagal dua kali.

Ini adalah perubahan kecil dalam package.json dari rest-frontend dan tidak ada masalah; tetapi saya tidak dapat melakukannya hanya untuk pekerjaan pembuatan beranda kami - itu akan dilakukan untuk semua instalasi.

Tentu saja.

Tapi saya tidak melihat keuntungan untuk jujur

Mungkin kita berbicara melewati satu sama lain, jadi idenya adalah:

make # juga mengkompilasi/membangun frontend, mungkin gagal
make install # hanya menyalin file, hanya gagal pada izin akses/disc penuh

Keuntungannya adalah jika kita entah bagaimana merusak translations/en.json, resources/structure.json.in, atau hal-hal penting lainnya, kita

1. memiliki make gagal (menjelaskan bahwa ada sesuatu yang salah di sini lebih awal)
2. membuat pekerjaan build gagal (karena 1.)
3. tidak memiliki instalasi parsial (instalasi tidak akan pernah dimulai jika make tidak berhasil lulus)

karena jika Anda memulai skrip pembuatan frontend, itu menghapus konten situs web dan membuatnya kembali selangkah demi selangkah melalui berbagai skrip. Dan karena skripnya sama untuk cmake dan skrip build, itu akan gagal dua kali.

Mungkin saya salah paham, tapi bagi saya make install sudah cukup untuk mendapatkan website baru, saya tidak mengeksekusi ulang script build frontend. Dalam situasi apa saya perlu menjalankan kembali skrip build frontend?

Mungkin skrip frontend seharusnya tidak menghapus konten situs web, tetapi membangun beberapa direktori sementara dan kemudian memindahkan direktori publik yang berhasil dibangun ke tujuannya?

Mungkin kita berbicara melewati satu sama lain, jadi idenya adalah:

Sekarang saya paham. Jika ada cara untuk membangun beranda di direktori biner, ini bisa berhasil. Saya tidak 100% yakin tentang jalur yang dikonfigurasi, harus melihatnya.

Dalam situasi apa saya perlu menjalankan kembali skrip build frontend?

Instalasi cmake dijalankan grunt install , sedangkan skrip build menjalankan grunt full . Satu-satunya perbedaan adalah bahwa grunt full juga membuat peta situs, yang memerlukan rest-backend untuk aktif (agar cuplikan dapat dicantumkan).

Mungkin skrip frontend seharusnya tidak menghapus konten situs web, tetapi membangun beberapa direktori sementara dan kemudian memindahkan direktori publik yang berhasil dibangun ke tujuannya?

Juga sebuah ide, tapi saya masih tidak yakin apakah itu sepadan dengan usaha. Kami tidak bisa membiarkan perintah grunt gagal sama sekali; maka kami selalu memiliki situs web yang berfungsi (jika tidak ada yang mengubah izin atau terjadi sesuatu yang bukan kesalahan skrip).

juga membuat peta situs, yang mengharuskan rest-backend untuk aktif

Ahh ok. Bukankah lebih baik jika skrip akan menghasilkan peta situs dan tidak ada yang lain? Mungkin kita bahkan bisa menjalankan ini sebagai cron job?

Kami tidak bisa membiarkan perintah grunt gagal sama sekali; maka kami selalu memiliki situs web yang berfungsi

Ya, selalu memiliki situs web yang berfungsi sejauh ini merupakan masalah terpenting di sini!

Ahh ok. Bukankah lebih baik jika skrip akan menghasilkan peta situs dan tidak ada yang lain? Mungkin kita bahkan bisa menjalankan ini sebagai cron job?

Anda juga dapat menjalankan setiap tugas secara terpisah, grunt full (yang sebenarnya adalah grunt default atau hanya grunt ) dan grunt install hanyalah daftar tugas yang dijalankan secara berurutan . Jadi ya, cronjob untuk peta situs akan masuk akal (tetapi kita harus berhati-hati agar file tidak ditulis dengan izin/pengguna yang salah, jika tidak, instalasi lain mungkin gagal).

Tetapi karena keseluruhan pembuatan front-end hanya membutuhkan beberapa detik, saya rasa menghapus skrip build dari pekerjaan build tidak akan banyak berdampak.

@e1528532 Bisakah Anda melihat apakah titik masuk utama situs web bagus (dan berikan perbaikan jika tidak)?

Terima kasih, situs yang bagus! Sekarang kita membutuhkan lebih banyak cuplikan ;)

Ini adalah masalah 1.0.0 pertama yang terpecahkan! :kembang api: