Auto: Perbaikan terbaru - Tambalan Dukungan untuk anak di bawah umur dan tambalan lama

@hipstersmoothie
Apakah Anda memiliki detail tentang bagaimana ini akan diterapkan / bagaimana tampilannya dalam praktik?

Juga, saya tidak yakin saya mengerti apa arti merge into a tag ... dapatkah Anda mengklarifikasi? Pemahaman saya adalah bahwa Anda hanya dapat membuat PR dengan cabang sebagai target.

Tidak, saya belum terlalu memikirkan masalah itu.

Juga, saya tidak yakin saya mengerti apa artinya bergabung menjadi tag

UI membuat saya percaya bahwa Anda mungkin dapat bergabung menjadi tag, tetapi setelah ditinjau lebih lanjut, ini sepertinya tidak mungkin. Jika kita bisa meskipun ini akan membuat ini mungkin.

Mengingat sedikit, saya pikir inilah yang saya pikirkan:

1. Tag 1.2.3 ada, versi saat ini adalah 2.0
2. PR dibuat menjadi tag 1.2.3, menghasilkan 1.2.3-0 (angka 0 adalah bagian build dari semver)

ok, memanfaatkan bagian build dari semver pasti masuk akal. 👍

Jika tidak mungkin membuat PR langsung ke tag, maka aliran ini mungkin mengharuskan pemilik repo untuk membuat cabang dari tag di cabang hulu (cabang target untuk PR). Ini akan sedikit mengganggu, tetapi saya tidak yakin apakah akan ada alternatif yang lebih baik. Selain itu, jenis rilis ini kemungkinan tidak umum, jadi mungkin ini akan baik-baik saja.

Pendekatan serupa dengan dukungan utama lama ( versionBranches ) dapat digunakan di mana awalan cabang dapat ditentukan dalam konfigurasi. Sepertinya fitur ini mungkin lebih ditargetkan ke rilis jenis perbaikan terbaru, jadi mungkin masuk akal untuk menjaga konfigurasi terpisah dari dukungan utama lama. Bagaimana menurutmu?

Contoh aliran mungkin terlihat seperti:

• pengguna menentukan dalam konfigurasi otomatis untuk membangun menggunakan pengidentifikasi build untuk cabang dengan awalan hotfix-
• log komit yang ada
  <ul> <li>(tag: v2.0.0) (master)<br /> |</li> <li>(tag: v1.2.0)<br /> |</li> <li>(tag: v1.1.0)<br /> |</li> <li>(tag: v1.0.0)<br />

Pendekatan serupa dengan dukungan utama lama (versionBranches) dapat digunakan di mana awalan cabang dapat ditentukan dalam konfigurasi.

Saya suka idenya tetapi dalam praktiknya saya tidak berpikir itu akan menyenangkan untuk digunakan. Karena auto merilis banyak, Anda akan berakhir dengan jumlah cabang yang gila.

Jika tidak mungkin membuat PR langsung ke tag, maka aliran ini mungkin mengharuskan pemilik repo untuk membuat cabang dari tag di cabang hulu (cabang target untuk PR). Ini akan sedikit mengganggu, tetapi saya tidak yakin apakah akan ada alternatif yang lebih baik. Selain itu, jenis rilis ini kemungkinan tidak umum, jadi mungkin ini akan baik-baik saja.

Saya setuju bahwa jenis pelepasan ini di luar norma. yang membuat pembuatan cabang otomatis kurang berguna. Anda akan mendapatkan banyak noise (lebih banyak cabang) tanpa menggunakannya terlalu banyak, jika pernah.

Adapun aliran yang Anda usulkan di atas tampaknya berfungsi dengan baik. Sayangnya kami tidak bisa membuat PR menjadi tag! akan membuat alur kerja ini lebih mudah.

Memikirkan hal ini, fitur ini mungkin memerlukan beberapa hal ke dalam auto untuk disempurnakan sepenuhnya:

1. Perintah baru auto hotfix : ketika dijalankan akan merilis proyek dengan versi hotfix baru berdasarkan tag terbaru di cabang
2. Fungsi baru untuk auto shipit : Mendeteksi jika kita berada di hotfixBranch dan menjalankan auto hotfix

Adapun cara kerja auto hotfix bisa dilakukan:

1. cara next atau canary => Kait baru yang memungkinkan plugin untuk mengontrol bagaimana hotfix dirilis apakah didukung sama sekali
2. gunakan kembali version dan publish hook dan buat mereka dapat melepaskan build semver

Dari dua opsi, saya pikir saya condong ke 1 karena memanggil kait version dan pubish dengan cara baru dapat dianggap sebagai perubahan yang melanggar. Kelemahannya adalah beberapa pengait tidak akan disebut afterVersion membuat beberapa plugin tidak berfungsi. Ini saat ini menjadi masalah untuk canary dan next sekalipun. karena mereka juga tidak menyebut kait itu. Jadi sesuatu yang tidak perlu dikhawatirkan segera.

Apakah Anda tertarik untuk mencoba menambahkan ini?

Saya suka idenya tetapi dalam praktiknya saya tidak berpikir itu akan menyenangkan untuk digunakan. Karena banyak rilis otomatis, Anda akan berakhir dengan jumlah cabang yang gila.

oops, maksudnya mirip dengan dukungan utama lama dalam hal memiliki konfigurasi awalan cabang. Sangat setuju bahwa membuat cabang secara otomatis akan menghasilkan terlalu banyak noise, terutama dengan pelepasan yang sering,

Memikirkan hal ini, fitur ini mungkin memerlukan beberapa hal ke dalam otomatis untuk disempurnakan sepenuhnya:

1. Perintah baru auto hotfix: ketika dijalankan akan merilis proyek dengan versi hotfix baru berdasarkan tag terbaru di cabang
2. Fungsionalitas baru untuk pengiriman otomatis: Deteksi jika kita berada di cabang perbaikan terbaru dan jalankan perbaikan terbaru otomatis

ya. Saya pikir itu sebagian besar akan merangkum perubahan yang diperlukan.

Adapun bagaimana perbaikan terbaru otomatis harus bekerja, itu bisa:

1. cara berikutnya atau canary => Kait baru yang memungkinkan plugin untuk mengontrol bagaimana perbaikan terbaru dirilis apakah itu didukung sama sekali
2. gunakan kembali versi dan publikasikan kait dan buat mereka dapat merilis build semver

Dari dua opsi, saya pikir saya condong ke 1 karena memanggil versi dan menerbitkan kait dengan cara baru dapat dianggap sebagai perubahan yang melanggar. Kelemahannya adalah beberapa kait tidak akan dipanggil afterVersion membuat beberapa plugin tidak berfungsi. Ini saat ini menjadi masalah bagi kenari dan selanjutnya. karena mereka juga tidak menyebut kait itu. Jadi sesuatu yang tidak perlu dikhawatirkan segera.

Tingkat tinggi, saya pikir 1 masuk akal juga. Saya perlu menelusuri kode untuk memiliki pemahaman yang lebih baik tentang kait mana yang dipanggil untuk perintah mana, tetapi jika next , canary , & hotfix semua mengikuti pola yang sama, maka setiap poin rasa sakit kemungkinan akan lebih mudah dipecahkan nanti.

Apakah Anda tertarik untuk mencoba menambahkan ini?

Tentu 👍, saya akan dengan senang hati melakukannya.
Saya mungkin tidak akan dapat melihat implementasi untuk ini sampai minggu depan, tetapi saya kira tidak apa-apa karena masalah ini belum diperbarui sejak Maret.

Luar biasa! Tidak ada pekerjaan yang direncanakan untuk yang satu ini jadi hanya Anda

FWIW - Saya akan mencoba membangun ini sebagai plugin dengan melakukan persis apa yang Anda anggap sebagai pilihan yang lebih rendah - membuat cabang version-MAJOR-MINOR . Tidak terasa terlalu banyak kebisingan atas proses kami saat ini, TBH. Kami sudah membuat cabang untuk setiap baris rilis.

Sebagian besar dari versionBranches saat ini adalah plugin ini :

    this.hooks.beforeCommitChangelog.tapPromise(
      "Old Version Branches",
      async ({ bump }) => {
        if (bump === SEMVER.major && this.config?.versionBranches) {
          const branch = `${this.config.versionBranches}${major(
            await this.hooks.getPreviousVersion.promise()
          )}`;

          await execPromise("git", [
            "branch",
            await this.git?.getLatestTagInBranch(),
          ]);
          await execPromise("git", ["push", this.remote, branch]);
        }
      }
    );

Tampaknya sepele untuk menambahkan dukungan untuk SEMVER.minor , tetapi saya akui saya tidak tahu bagian mobil apa yang mungkin perlu diubah.

Itu bagian dari apa yang terjadi untuk rilis lama tetapi kemudian pemeriksaan ini di shipit juga harus lulus

https://github.com/intuit/auto/blob/f37945b45b7fef6ffdb00ffa0250de449e02b883/packages/core/src/auto.ts#L1442

Yang kemudian pergi ke sini dan pada dasarnya hanya menimpa tempat untuk mulai menghitung rilis dari

https://github.com/intuit/auto/blob/f37945b45b7fef6ffdb00ffa0250de449e02b883/packages/core/src/auto.ts#L1509

Satu-satunya pertimbangan yang harus kita buat dengan minor/tambalan lama dan bukan mayor adalah kemungkinan ketidakcocokan versi. Dengan anak di bawah umur, itu mungkin bukan masalah

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.1.1)
|
|  *  (tag: v1.1.2) <- Need to add logic to find an available tag 
| /
*  (tag: v1.1.0) (hotfix-feature)
|
*  (tag: v1.0.0)

Jadi mungkin perintah hotfix tidak diperlukan. Sebaliknya itu hanya bisa mencoba nomor versi unik. Mungkin perlu ada validasi di sekitar ini.

Aturan :

1. tidak dapat merilis mayor di cabang rilis minor/tambalan lama mana pun (wajib)
2. tidak dapat merilis minor di cabang rilis patch lama mana pun (mungkin tidak perlu?)

@hipstersmoothie
Tahukah Anda apa perilaku default sekarang jika Anda memiliki pengaturan ci untuk membangun dari tag yang lebih lama, di mana tag berikutnya tidak tersedia?

Dugaan saya, apakah akan ada kegagalan, meskipun saya tidak yakin di mana kesalahan ini akan terjadi (mungkin di tag push?).

yaitu:

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.1.1)
|
|  *   <- what is current behavior if I try to release this commit
| /
*  (tag: v1.1.0) 
|
*  (tag: v1.0.0)

Di luar menegakkan aturan yang ditentukan @hipstersmoothie , saya melihat satu potensi masalah/kebingungan dengan strategi/implementasi try to unique version number . Untuk contoh yang diberikan @hipstersmoothie , v1.1.2 akan dilihat oleh orang lain sebagai rilis patch dari v1.1.1 , tetapi karena pengembangannya tidak linier, ini tidak dijamin. Berpotensi, bahkan mungkin ada perubahan yang tidak kompatibel ke belakang dari v1.1.1 menjadi v1.1.2 karena kemungkinan v1.1.2 tidak memiliki perubahan dari v1.1.1 . Ini bisa menjadi lebih buruk dan lebih membingungkan jika versi unik berikutnya lebih jauh dari v1.1.0 (yaitu: bagaimana jika versi unik berikutnya adalah v1.1.100 ?)

Memanfaatkan bagian metadata build dari semver akan membatasi kebingungan ini karena menurut spesifikasi semver, ini diabaikan saat menghitung prioritas versi. Jika menambah nomor metadata build, maka mungkin commit sha dapat digunakan sebagai ganti nomor yang bertambah.

Secara umum, pengembangan perangkat lunak tidak selalu linier, jadi tidak yakin ada implementasi terbaik.

Jika kita ingin menggeneralisasi, maka mungkin kita bisa memiliki semacam konfigurasi atau pengait untuk menentukan strategi di atas terlepas dari cabang (atau cabang bisa menjadi parameter untuk pengait).
Dengan cara ini, implementasi yang berbeda dapat digunakan melalui plugin.

Tahukah Anda apa perilaku default sekarang jika Anda memiliki pengaturan ci untuk membangun dari tag yang lebih lama, di mana tag berikutnya tidak tersedia?

Biasanya tag tidak dibuat karena komit memiliki [skip ci] dalam pesan

Ini bisa menjadi lebih buruk dan lebih membingungkan jika versi unik berikutnya adalah jarak yang lebih jauh dari v1.1.0

Ini adalah poin yang bagus. Jelas menjadikan bagian metadata build dari versi sebagai strategi yang tepat.

Jika kita ingin menggeneralisasi, maka mungkin kita bisa memiliki semacam konfigurasi atau pengait untuk menentukan strategi di atas terlepas dari cabang (atau cabang bisa menjadi parameter untuk pengait).
Dengan cara ini, implementasi yang berbeda dapat digunakan melalui plugin.

posting Anda cukup meyakinkan saya bahwa menemukan tag unik adalah skema yang membingungkan untuk dilakukan dan kami mungkin tidak seharusnya melakukannya.

Mungkin jika kita melakukan campuran meskipun itu bisa berhasil. Menambal dan minor lama seharusnya mudah. Itu bisa bekerja dengan cara yang sama persis seperti oldVersionBranches untuk jurusan:

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.2.0)
|
|  *  (tag: v1.1.5) <- Can merge patched into old minor branch, maybe error when PR has `minor`
| /
*  (tag: v1.1.4) <- branch: version-1.1
|
*  (tag: v1.0.0)

Kemudian kita hanya perlu melakukan bagian build metadata untuk patch patch.

Dengan opsi from dan useVerion digabungkan, apakah ada cara bawaan untuk melakukan perbaikan terbaru? Saya baru saja membuatnya hari ini dan memilih untuk melakukannya dengan susah payah secara manual.

Untuk konteks, proyek saya ada di 7.7. Konsumen utama proyek kami saat ini merilis versi yang ada di 7.5, menemukan masalah dan membutuhkan 7.5.1 sehingga mereka tidak perlu melakukan QA ulang semuanya di pertengahan rilis. Tidak optimal, tetapi kadang-kadang terjadi.

Masih tidak ada cara untuk melakukan ini sepengetahuan saya tanpa intervensi manual. Saya pikir seseorang secara internal di sini di intuisi berencana untuk menambahkan ini pada akhirnya. Saya setuju ini adalah fitur yang sangat hilang di auto

Mengagumkan untuk didengar! Terima kasih 🙏

Kami (saya dan @10hendersonm) mengembangkan solusi untuk ini tetapi cukup
terlibat. Namun itu hanya menggunakan otomatis dan plugin!

Kami baru saja memperbaiki 7.2.1, 8.1.1, dan 8.2.2 proyek kami hanya menggunakan PR
(dengan sangat hati-hati).

Kita bisa melihat bagaimana cara membagikan ini jika orang tertarik?

Pada Kamis, 14 Januari 2021, 19:27 Matt Felten [email protected] menulis:

Mengagumkan untuk didengar! Terima kasih 🙏

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/intuit/auto/issues/1054#issuecomment-760583830 , atau
berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AACI3Q6RKDONYJVH6UWUPFLSZ6KZNANCNFSM4LFJ4ULQ
.

Saya akan sangat tertarik!

Halo semua! Saya tertarik untuk berkontribusi dalam hal ini. Usulan saya adalah sebagai berikut:

1. Secara umum, auto akan mencoba untuk menghormati cabang version-* . Misalnya tambalan yang digabungkan dari cabang mana pun menjadi version-1.1.4 akan menghasilkan rilis versi 1.1.5 . Jika versi itu telah dibuat, maka rilis NPM atau Git Tag akan gagal, tetapi itu adalah kasus kesalahan yang normal dan diharapkan
2. Kami dapat memperbarui versionBranches untuk menerima "major" | "minor" | "patch" , yang akan menghasilkan cabang hotfix potensial berdasarkan apa yang Anda tentukan. Ini memungkinkan Anda untuk memilih trade-off antara secara manual perlu membuat cabang version-* dan berakhir dengan terlalu banyak cabang untuk dipelihara saat Anda tidak memerlukan perbaikan

Pikiran?

tetapi itu adalah kasus kesalahan yang normal dan diharapkan\

Saya masih mengharapkan ini untuk membuat beberapa jenis versi. Saya baru-baru ini memiliki kasus di mana saya ingin merilis perbaikan terbaru dari komit tertentu untuk tidak menarik apa pun. Saya pikir dalam hal ini kita bisa menggunakan bagian build dari semver dari percakapan di atas.

Kami dapat memperbarui versionBranches untuk menerima "utama" | "kecil" | "tambalan"

Konfigurasi saat ini dapat berupa true atau string untuk mengawali cabang utama. Saya pikir konfigurasi baru harus terlihat seperti

{
  "versionBranches": {
      "branchPrefix": "version-",
      "types": ["major", "minor"] // defaults to just major   
   }
}

Pertanyaan terakhir yang harus dijawab adalah masih hotfix hook atau call version+publish hooks melihat kode untuk implementasi cabang versi lama saat ini, kami melakukan opsi 2 dan memanggil versi+publish (dan saya pikir ini secara keliru menerbitkan ke tag terbaru).

@lshadler Kami banyak yang perlu memasangkan ini sebentar untuk menemukan pendekatan terbaik.

@bmuenzenmeyer Bisakah Anda memberikan gambaran tentang pendekatan Anda?

Semakin saya berpikir tentang implementasi, saya pikir ini akan memerlukan v11 dan lebih banyak konteks ditambahkan ke versi dan menerbitkan perintah.

Untuk rilis lama, kami memerlukan saluran lengkap terbaru untuk dijalankan dengan changelog, afterVersion, dan semua atau kaitnya yang dipanggil selama rilis terbaru.

Kita mungkin harus membuat rilis berikutnya memiliki versi yang sama afterVersion publish afterPublish flow terbaru. Itu bisa menjadi bagian dari v11 juga. Ini harus sesuai dengan alur kerja terbaru sehingga Anda dapat menambahkan otomatisasi serupa.

Alur kerja Canary dapat tetap sama karena tidak ada yang dilakukan untuk canary dan Anda sudah dapat mengetuk canary hook untuk melakukan lebih banyak hal.

Halo semua, dengan kegilaan tahun lalu, sayangnya masalah ini telah hilang dari saya.

Mengenai pendekatan yang berbeda, saya pikir mungkin membantu untuk mempertimbangkan berbagai kasus penggunaan yang dipecahkan oleh fitur-fitur ini. Menurut pendapat saya, saya dapat melihat 2 kasus penggunaan:

• (1) dukungan jangka panjang untuk cabang lama (yaitu: versi utama lama)
• (2) dukungan jangka pendek untuk versi tertentu (yaitu: hotfix)

Berdasarkan percakapan ini, saya pikir masuk akal untuk memiliki pendekatan yang berbeda untuk masing-masing kasus penggunaan tersebut.

(1) Untuk dukungan jangka panjang dari trek cabang/rilis, saya yakin versionBranches harus dapat dipecahkan. Jika ada keinginan untuk memperluas perilaku ini untuk versi minor (seperti yang telah disebutkan beberapa di atas), maka itu bisa menjadi peningkatan fungsi itu.

(2) Untuk dukungan jangka pendek/perbaikan terbaru, berdasarkan utas di atas, saya pikir harus ada cara standar bagi pengguna untuk selalu menggunakan bagian build dari semver untuk menghasilkan rilis perbaikan terbaru. Ini memberikan perilaku yang konsisten bagi Pemilik Kode untuk digunakan dan menghindari beberapa skenario kasus sudut yang rumit. Untuk kasus ini, saya pikir perintah dan pengait hotfix baru dapat digunakan. Ini bisa menjadi peningkatan yang berbeda. Secara umum, kasus penggunaan ini seharusnya relatif jarang karena konsumen harus didorong untuk menggunakan versi terbaru jika memungkinkan.

edit _(Untuk kasus penggunaan jangka pendek, kemungkinan konfigurasi versionBranches dapat diperluas untuk memungkinkan parameter / toggle / flag yang menunjukkan apakah akan menghormati label semver untuk cabang version- atau untuk selalu menggunakan bagian build dari semver dan abaikan label apa pun untuk cabang tersebut)_

Apakah ada kasus penggunaan lain selain 2 ini yang harus dipertimbangkan?

Haruskah pendekatan yang berbeda dipertimbangkan untuk kasus penggunaan yang berbeda?

(juga, saya masih dapat membantu dengan beberapa perubahan ini, tetapi jelas tidak ingin memblokir orang lain untuk mengambil perubahan untuk ini)

juga, pemikiran tangensial untuk pola percabangan:

auto akan menghasilkan tag git (rilis) untuk rilis. Ini berarti bahwa git ref yang valid didorong ke github. Untuk kasus penggunaan dukungan jangka pendek (yaitu: cabang jangka pendek / cabang perbaikan terbaru), ini berarti pengguna dapat menghapus cabang jangka pendek setelah rilis / tag git didorong.

• diberikan cabang master dengan tag berikut
  <ul> <li>(tag: v1.3.0) (master)<br /> | </li> <li>(tag: v1.2.3)<br />

Untuk cabang yang berumur pendek, mungkin baik untuk mendokumentasikan pola percabangan di atas saat menambahkan fitur. Saya pribadi menemukan bahwa banyak yang tidak menyadari bahwa Anda dapat menghapus cabang dan masih memiliki referensi ke komit baru, yang dapat membantu berbagai proyek untuk mengurangi kekacauan cabang yang berumur pendek.

Saya baru-baru ini bermain-main dengan kode untuk memanfaatkan bagian build dari semver untuk membuat build. Ketika saya melakukannya, saya menemukan kasus penggunaan di mana rilis github terbaru belum tentu versi semantik terbaru/tertinggi.

Misalnya, dalam contoh yang disebutkan di sini: https://github.com/intuit/auto/issues/1054#issuecomment -780286683, rilis github terbaru akan ditampilkan sebagai v1.2.3+1 karena dibuat sementara setelah yang tertinggi versi versi semantik: v1.3.0 .

Karena beberapa tempat dalam referensi kode getLatestRelease , ini dapat menyebabkan perilaku yang bervariasi jika pipeline tidak secara eksplisit menetapkan parameter from . yaitu:

• apa yang termasuk dalam catatan rilis
• apa versi sebelumnya dihitung sebagai
• berpotensi merusak fungsionalitas jika rilis github terbaru tidak dapat dijangkau dari komit HEAD

Saya belum menguji, tetapi saya yakin jenis skenario ini juga dapat dijangkau melalui perilaku versionBranches . Saya percaya ini terkait dengan komentar mengenai aliran mana yang harus menghasilkan tag git/rilis github:

Pertanyaan terakhir yang harus dijawab adalah masih hotfix hook atau call version+publish hooks melihat kode untuk implementasi cabang versi lama saat ini, kami melakukan opsi 2 dan memanggil versi+publish (dan saya pikir ini secara keliru menerbitkan ke tag terbaru).

Dalam hal penyelesaian, masalah ini kemungkinan dapat diselesaikan secara independen dari pemfaktoran ulang kait dengan mengganti logika getLatestRelease dengan:

• (1) ambil rilis github menggunakan listReleases dan kemudian urutkan untuk menemukan versi rilis tertinggi (tidak ada bagian prarilis atau build) yang dapat dijangkau
• (2) atau ambil tag git dan kemudian urutkan untuk menemukan versi rilis tertinggi (tidak ada bagian prarilis atau build) yang dapat dijangkau

Perbedaannya di sini adalah apakah auto melihat rilis github atau tag git sebagai sumber kebenaran, yang terkait dengan diskusi https://github.com/intuit/auto/discussions/1867#discussioncomment -684192.

Saya awalnya akan condong ke arah (2), karena

• (a) kita pada akhirnya mengejar git ref (tag) dan bukan elemen lain dari rilis github
• (b) itu akan mengurangi jumlah panggilan jaringan

@hipstersmoothie ,
Jika kami perlu memodifikasi logika getLatestRelease , apa pendapat Anda tentang (1) menggunakan rilis github vs (2) menggunakan tag git vs (3) sesuatu yang lain?

Ya agar multi paket otomatis berfungsi, ia perlu memfaktorkan ulang semua hal rilis GitHub terbaru menjadi hanya tag. 2 adalah pilihan yang pasti untuk menyelesaikan pekerjaan ini.