kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
community/contributors/guide/contributor-cheatsheet/README-id.md

16 KiB
Raw Blame History

Cheat Sheet Kontributor Kubernetes

Kumpulan resources umum yang digunakan ketika berkontribusi ke Kubernetes, termasuk tips, trik, dan best practices yang digunakan di dalam proyek Kubernetes. Ini merupakan referensi singkat ("TL;DR") informasi yang bermanfaat untuk meningkatkan pengalaman kamu ketika berkontribusi di GitHub menjadi lebih baik.

Daftar Isi

Sumber Penting

Mulai Berkontribusi

SIG dan Grup Lainnya

Komunitas

Workflow

Testing

  • Prow - Mekanisme CI/CD Kubernetes.
  • Test Grid - Melihat data historical testing beserta informasi terkait.
  • Dasbor Triase - Melakukan agregasi failure untuk mekanisme troubleshoot yang lebih baik.

Alamat Email Penting

Tautan Lain

Berkomunikasi Secara Efektif di GitHub

Bagaimana Cara Bekerja Sama dengan Baik

Pada tahap awal, pelajari dan pahami Code of Conduct.

Contoh Komunikasi Yang Baik/Buruk

Ketika membuka sebuah isu, atau mencari bantuan, tolong bersikap dengan sopan ketika melakukan hal tersebut:

🙂 “X tidak dapat dikompilasi, apakah kamu memiliki saran?”

😞 “X tidak bekerja sebagaimana mestinya! Tolong perbaiki!”

Ketika menutup sebuah PR, berikan penjelasan yang rinci mengenai alasan kenapa PR tersebut tidak memenuhi standar untuk di-merge.

🙂 “Aku menutup PR ini karena fitur ini tidak mendukung kebutuhan X. Sesuai kesepakatan, akan lebih baik jika ini diimplementasikan dengan Y. Terima kasih sudah menyempatkan waktu untuk mengerjakan hal ini."

😞 “Mengapa PR ini tidak mengikuti konvensi API? Hal ini harusnya tidak dilakukan di sini!"

Mengumpulkan Kontribusi

Menandatangani CLA

Sebelum kamu mengumpulkan kontribusi kamu, kamu harus terlebih dahulu menyetujui Contributor License Agreement(CLA). Proyek Kubernetes hanya menerima kontribusi yang kamu kerjakan apabila kamu sudah menyetujui CLA.

Apabila kamu kesulitan ketika menyetujui CLA, ikuti petunjuk troubleshooting CLA.

Membuka dan Menanggapi Isu

Isu GitHub merupakan mekanisme tracking berbagai hal yang ada, termasuk pelaporan bug, permintaan peningkatan fitur, atau pelaporan isu lainnya seperti terjadi kegagalan ketika menjalankan test. Hal tersebut tidak diperuntukkan bagi user support request. Untuk tujuan tersebut, kamu bisa membaca petunjuk troubleshooting, laporkan permasalahan yang ada ke Stack Overflow atau ikuti forum Kubernetes.

Referensi

Membuat Sebuah Isu

  • Gunakan templat isu (jika tersedia). Menggunakan templat yang tersedia akan memudahkan kontributor lain ketika menanggapi isu yang kamu buat.
    • Ikuti petunjuk yang dideskripsikan di templat tersebut.
  • Berikan deskripsi yang cukup ketika membuat suatu isu.
  • Gunakan label yang tepat. Jika kamu kurang yakin, k8s-ci-robot bot (Kubernetes CI bot) akan membalas isu yang kamu buat dengan respons needed labels.
  • Selektiflah ketika meng-assign suatu isu menggunakan /assign @<username> atau /cc @<username>. Isu yang kamu buat akan ditriase secara lebih efektif apabila kamu menambahkan label yang tepat.

Menanggapi sebuah Isu

  • Ketika menghadapi sebuah isu, berikan komentar terhadap isu tersebut yang menandakan kamu sedang mengerjakan isu tersebut untuk mencegah pengerjaan berulang.
  • Ketika kamu sudah menyelesaikan hal tersebut, berikan komentar yang mengindikasikan kamu sudah menyelesaikannya sebelum kamu menutup isu tersebut, hal ini bertujuan agar orang lain tahu alasan kenapa kamu menutup isu tersebut.
  • Masukkan referensi ke PR atau isu lain (atau material lain yang dapat diakses)
    misalnya "ref: #1234". Hal ini nantinya dapat digunakan untuk mengidentifikasi hal terkait yang mungkin sudah dibahas/dikerjakan di tempat lain.

Membuka sebuah Pull Request (PR)

Pull requests (PR) adalah mekanisme utama yang digunakan untuk melakukan kontribusi kode, dokumentasi, atau segala bentuk hal yang disimpan dalam repositori git.

Referensi:

Membuat sebuah Pull Request (PR)

  • Ikuti petunjuk yang ada pada templat PR (jika tersedia). Menggunakan templat yang tersedia akan memudahkan kontributor lain ketika menanggapi PR yang kamu buat.
  • Jika hal tersebut merupakan trivial fix seperti tautan yang broken, typo atau kesalahan grammar, review dokumen secara menyeluruh untuk mengecek apakah terjadi kesalahan yang serupa. Jangan membuka multipel PR untuk fix kecil pada dokumen yang sama.
  • Berikan referensi ke isu yang terkait dengan PR kamu, atau isu lain yang mungkin dapat diselesaikan dengan PR yang kamu buat.
  • Hindari perubahan yang sangat besar dalam suatu commit, Sebaliknya, pisahkan PR kamu dalam multipel PR yang lebih kecil. Ini akan memudahkan proses review PR yang kamu buat.
  • Berikan komentar pada PR yang kamu buat, apabila kamu merasa ada hal yang membutuhkan penjelasan lebih lanjut.
  • Selektiflah ketika meng-assign suatu isu menggunakan /assign @<username>. Meng-assign reviewer secara berlebihan tidak mempercepat proses review yang dilakukan untuk PR kamu.
  • Jika PR kamu masih dalam tahap "Work in progress" berikan prefiks [WIP] atau gunakan perintah /hold. Hal ini mencegah agar PR tidak di-merge hingga WIP dihilangkan.
  • Jika PR kamu tidak di-review, jangan tutup PR tersebut dan membukan PR lain dengan perubahan yang sama. Ping reviewer PR kamu dengan komentar @<github username>.

Contoh Deskripsi PR

Ref. #3064 #3097
Semua file yang dimiliki oleh SIG testing dipidahkan dari folder `/devel` ke folder `/devel/sig-testing`.

/sig contributor-experience
/cc @stakeholder1 @stakeholder2
/kind cleanup
/area developer-guide
/assign @approver1 @approver2 @approver3

Apa saja yang dimasukkan dalam deskripsi:

  • Baris 1 - Referensi ke isu atau PR lain (#3064 #3097).
  • Baris 2 - Deskripsi singkat mengenai apa yang dikerjakan dalam PR tersebut.
  • Baris 4 - SIG assignment dengan perintah /sig contributor-experience..
  • Baris 5 - Reviewer yang terkait dengan isu atau PR yang dispesifikasikan dengan perintah /cc.
  • Baris 6 - Perintah /kind cleanup menambahkan label yang mengkategorisasi isu atau PR yang terkait untuk membersihkan kode, process, atau technical debt.
  • Baris 7 - Perintah /area developer-guide mengkategorisasi isu atau PR yang terkait dengan petunjuk pengembang.
  • Baris 8 - Perintah /assign meng-assign seorang approver untuk PR. Seorang approver akan disarankan oleh k8s-ci-robot dan dipilih dari list owner pada file [OWNERS]. Merekalah yang akan menambahkan label /approve pada PR yang sudah di-review.

Troubleshooting sebuah PR

Setelah PR kamu diajukan, serangkaian testing akan dijalankan oleh platform CI Kubernetes, Prow. Jika terdapat salah satu test yang gagal, maka k8s-ci-robot akan memberikan balasan pada PR kamu beserta tautan yang memberikan log dari testing yang gagal dijalankan.

Apabila kamu mem-push commit baru, test pada PR kamu akan secara otomatis di-trigger.

Terkadang, bisa jadi terdapat masalah pada platform CI Kubernetes. Hal ini dapat terjadi karena berbagai alasan bahkan ketika test yang kamu jalankan di mesin lokal kamu berhasil. Kamu dapat men-trigger ulang test dengan cara memanggil perintah /retest.

Untuk informasi lebih lanjut, baca Panduan Testing.

Label

Kubernetes menggunakan label untuk melakukan kategorisasi dan triase isu dan PR. Penggunaan label yang benar akan membuat triase pada isu atau PR yang kamu ajukan menjadi lebih efektif.

Referensi:

Label yang sering digunakan:

Bekerja pada Mesin Lokal

Sebelum kamu membuat sebuah PR, sebagian besar kamu akan mengerjakan pekerjaan kamu pada mesin lokal. Jika kamu merupakan pengguna baru git, Tutorial git Atlassian merupakan awal pembelajaran yang baik. Sebagai alternatif lain, juga terdapat tutorial Stanford's Git magic untuk pilihan multi-bahasa yang bagus.

Referensi:

Mekanisme Branch

Proyek Kubernetes menggunakan mekanisme "Fork and Pull" yang merupakan standar GitHub. Dalam terminologi git, fork yang kamu buat disebut sebagai "origin" dan git proyek yang sebenarnya disebut sebagai "upstream". Untuk menjaga branch (origin) tetap up to date dengan proyek (upstream), branch tersebut harus dikonfigurasikan pada copy lokal.

Menambahkan Upstream

Tambahkan upstream sebagai remote, dan atur agar kamu tidak dapat mem-push ke sana.

# ganti <upstream repositori git> dengan url upstream repositori
# contoh:
#  https://github.com/kubernetes/kubernetes.git
#  git@github.com/kubernetes/kubernetes.git

git remote add upstream <upstream git repo>
git remote set-url --push upstream no_push

Versifikasi langkah ini dapat dilakukan dengan cara menjalankan git remote -v yang selanjutnya akan menampilah seluruh remote yang sudah kamu atur.

Menjaga agar Fork Kamu tetap Sinkron

Fetch semua perubahan dari upstream dan lakukan "rebase" pada master branch lokal kamu. Dengan demikian repositori lokal kamu akan tertap sinkron dengan proyek upstream.

git fetch upstream
git checkout master
git rebase upstream/master

Kamu setidaknya harus melakukan hal ini sebelum membuat sebuah branch baru yang akan kamu gunakan untuk mengerjakan fitur baru atau melakukan fix.

git checkout -b myfeature

Melakukan Commit Squashing

Tujuan utama dari commit squashing adalah untuk membuat histori atau log git yang mudah dibaca dan bersih. Biasanya hal ini dilakukan pada fase akhir dari revisi yang kamu buat. Jika kamu masih belum yakin apakah kamu harus melakukan commit squashing atau tidak, biarkan revisi kamu apa adanya sampai ada saran khusus dari kontributor yang di-assign untuk me-review atau meng-approve revisi kamu apakah commit squashing perlu dilakukan atau tidak.