การโอนย้ายจาก GitLab ไปยัง GitHub｜แนะนำวิธีการจากการเปรียบเทียบไปสู่การใช้งานจริง

คันโนะ

สวัสดี ฉันชื่อ Sugano ผู้จัดการที่รักการพัฒนาและรักราเมน

เราใช้ GitLab เป็นเวลานานที่ Sun-El แต่เราได้ตัดสินใจย้ายไปยัง GitHubเว็บไซต์อย่างเป็นทางการของ GitLabเนื่องจากแผนบริการฟรีจำกัดผู้ใช้ 5 คนต่อเนมสเปซตั้งแต่วันที่ 19 ตุลาคม 2022 ตามที่อธิบายไว้ใน ไม่ใช่ว่าฉันไม่พอใจกับฟังก์ชันการทำงานของ GitLab แต่ฉันจะยังคงใช้มันต่อไปหากไม่ใช่สำหรับการเปลี่ยนแปลงนี้ เช่นเดียวกับ Docker เป็นเพราะ GitLab เผยแพร่สู่สาธารณะหรือไม่ ตอนนี้ GitHub มีพื้นที่เก็บข้อมูลส่วนตัวฟรี แต่ GitLab ดูเหมือนจะมีข้อจำกัดที่เข้มงวดกว่าในระดับฟรี ดูเหมือนว่ามีผู้คนจำนวนมากที่ถูกโยกย้ายด้วยการเปลี่ยนแปลงนี้

ในบทความนี้ ฉันจะแนะนำสิ่งที่ฉันได้เรียนรู้หลังจากย้ายข้อมูลไปยัง GitHub ผ่านกระบวนการพิจารณาเบื้องต้น ฉันหวังว่าจะเป็นประโยชน์สำหรับผู้ที่อยู่ระหว่างการรวบรวมข้อมูลเกี่ยวกับการย้ายถิ่นและผู้ที่กำลังพิจารณาว่าจะแนะนำสิ่งใด

เกี่ยวกับสถานการณ์ของ San-El ก่อนย้ายไป GitHub และกลุ่มเป้าหมายของบทความนี้

ก่อนที่ฉันจะเข้าสู่หัวข้อหลัก ฉันอยากจะแนะนำสถานการณ์ของ San-El ก่อนการย้ายไปยัง GitHub

• ใช้ GitLab มานานกว่า 10 ปี
• GitLab มีวิศวกร 7 คน ผู้ทดสอบ 3 คน และผู้จัดการโครงการ 3 คน
• GitLab CI ถูกใช้เพื่อสร้าง CI/CD
• GitHub ถูกนำมาใช้เพื่อเหตุผลของโครงการ เช่น การส่งมอบ

โปรดทราบว่าบทความนี้ไม่ได้อธิบายพื้นฐานของ Git หรือวิธีติดตั้ง node.js

ขั้นตอนตั้งแต่การตรวจสอบเปรียบเทียบ GitLab และ GitHub ไปจนถึงการย้ายข้อมูล

บทสรุป

สำหรับผู้ที่ต้องการภาพรวมอย่างรวดเร็วของความแตกต่างระหว่าง GitLab และ GitHub นี่คือข้อสรุปของฉันก่อน

• หากสเกลเป็น 5 หรือน้อยกว่า GitLab นั้นฟรี คุณจึงใช้งานได้หากต้องการ
• GitHub หากคุณไม่สามารถจ่าย $19/เดือนต่อคนได้ GitHub ฟรีหรือ $4/เดือนต่อคน
• $19/เดือนออกฟังก์ชั่นการจัดการโครงการGitLab ถ้าคุณให้ความสำคัญ
• หากค่าใช้จ่ายในการเรียนรู้เป็นสิ่งสำคัญ GitHub GitLab มีผู้ใช้ (โดยเฉพาะในญี่ปุ่น) น้อยกว่า GitHub

ตอนที่ 1 พิจารณาว่าจะใช้ GitLab ต่อหรือไม่

ถ้าฉันต้องการใช้ GitLab ต่อไป ฉันมีสามตัวเลือก:

1. หลีกเลี่ยง 5 ผู้ใช้ต่อเนมสเปซ
2. อัปเกรดเป็นเวอร์ชันที่ต้องชำระเงิน
3. โอนย้ายไปยังเวอร์ชันที่จัดการด้วยตนเองซึ่งคุณตั้งค่าเซิร์ฟเวอร์ของคุณเอง

ประการแรกคือการปฏิเสธทันที พูดง่ายๆ คือ คุณสามารถใช้คนได้สูงสุด 5 คนต่อโปรเจ็กต์ นอกจากนี้การจัดการยังค่อนข้างซับซ้อน ถัดไปคือ 2,วางแผนมีเพียงสามรายการเท่านั้น ฟรี พรีเมียม และขั้นสูงสุด และพรีเมียมมีค่าใช้จ่าย $19 เฮ้ ฉันไม่อยากจ่ายเงินจำนวนนั้น ส่วนที่เหลือคือ 3 แต่เดิม Sanel ใช้เวอร์ชันที่จัดการด้วยตนเอง และเมื่อสองปีที่แล้ว อย่างไรก็ตาม เราต้องย้ายข้อมูลไปยังเวอร์ชันคลาวด์ เพราะไม่เพียงแต่ต้องบำรุงรักษาเซิร์ฟเวอร์เท่านั้น แต่ยังต้องอัปเกรดเวอร์ชันด้วยตัวเองด้วย ดังนั้นฉันจึงไม่รู้สึกอยากกลับไปใช้เวอร์ชันที่จัดการด้วยตนเอง
ดังนั้นฉันจึงตัดสินใจย้ายจาก GitLab ไปยัง GitHub

ส่วนที่ 2 การพิจารณาแผนการกำหนดราคาของ GitHub

GitHub มี 3 แผน ได้แก่ ฟรี ทีม และองค์กร และทีมคือ 1 TP4T4 ต่อผู้ใช้ต่อเดือน มันค่อนข้างสมเหตุสมผลเมื่อเทียบกับ GitHub Enterpise คือ $21 คุณจึงเห็นได้ว่า GitLab มีราคาแพงเพียงใด ในตอนแรก GitLab มีฟังก์ชันการจัดการโครงการค่อนข้างมาก ดังนั้นฉันคิดว่าคุณไม่ควรเปรียบเทียบราคาง่ายๆ ตั้งแต่แรก

เปรียบเทียบแต่ละแผนเว็บไซต์อย่างเป็นทางการและปล่อยให้เว็บไซต์อื่น ๆ ฉันคิดว่าสองประเด็นต่อไปนี้เป็นประเด็นว่า Free ดีหรือไม่

1. ฉันไม่สามารถสร้างโทเค็นองค์กรได้
2. ฉันไม่สามารถสร้างคำขอดึงแบบร่างได้
3. ไม่สามารถตั้งค่าสาขาที่ได้รับการป้องกัน

ก่อนหน้านี้ พื้นที่เก็บข้อมูลส่วนตัวมีขีดจำกัด ดังนั้นเมื่อบริษัทต่างๆ ใช้เวอร์ชันที่ต้องชำระเงิน (ทีม) จึงจำเป็นต้องใช้ แต่ตอนนี้คุณสามารถสร้างพื้นที่เก็บข้อมูลส่วนตัวได้ไม่จำกัดแม้ว่าจะเป็นเวอร์ชันฟรีก็ตาม ด้วยเหตุนี้ ถ้าสองจุดนี้ไม่มีปัญหา ผมว่าฟรีก็พอ แน่นอน ฉันคิดว่ามันขึ้นอยู่กับตำแหน่งที่คุณให้ความสำคัญ แต่ Sanel ใช้ Notion สำหรับการจัดการเอกสาร ดังนั้น GitHub Wiki จึงไม่จำเป็น และ 2,000 นาทีต่อเดือนสำหรับ GitHub Actions ก็เพียงพอแล้ว

ค่อนข้างไม่สะดวกที่จะไม่สามารถใช้โทเค็นองค์กรของ 1 และแต่ละโครงการต้องใช้ PAT (โทเค็นการเข้าถึงส่วนบุคคล) ของผู้ใช้ที่รับผิดชอบ แต่มันไม่ดีสำหรับการจัดการ ดังนั้นจึงค่อนข้างมีปัญหา 2 และ 3 เป็นฟังก์ชันที่สามารถใช้ได้แม้ใน GitLab เวอร์ชันฟรี ดังนั้นจึงเป็นเรื่องที่น่าปวดหัวหากไม่สามารถใช้งานได้ มันจะนำไปสู่อุบัติเหตุในการปฏิบัติงาน ดังนั้นขนาดของการพัฒนา เช่น การสร้าง CI/CD จึงเป็นเรื่องยากสำหรับ Free

ที่ San-El เราใช้เวอร์ชันฟรีในขณะนี้และย้ายไปยังเวอร์ชันนั้น แต่เนื่องจากทั้งสองจุดนี้เป็นปัญหา เราจึงวางแผนที่จะเปลี่ยนเป็นเวอร์ชันสำหรับทีมในอนาคต

ส่วนที่ 3 ความประทับใจในการย้ายข้อมูลไปยัง GitHub

มันเป็นจุดที่ดี

การรวม Slack ที่สะดวก

สำหรับฉันนี่คือสิ่งที่ดีที่สุด คุณยังสามารถเชื่อมโยงกับ GitLab ได้ แต่เนื่องจากไม่มีกลไกการลงชื่อเข้าใช้ เนื้อหาของปัญหาจะไม่แสดงบน Slack ในการเปรียบเทียบ GitHub ช่วยให้คุณเห็นเนื้อหาของปัญหาจาก Slack และคุณยังสามารถแสดงความคิดเห็นและปิดได้ นอกจากนี้ หากคุณลงชื่อเข้าใช้ GitHub จาก Slack ชื่อบัญชี GitHub ของคุณจะถูกแปลงเป็นชื่อบัญชี Slack ดังนั้นคุณจะถูกกล่าวถึงใน Slack อย่างแน่นอน GitLab ไม่สะดวกอย่างยิ่งสำหรับสิ่งนี้ สันนิษฐานว่าสามารถติดตั้งแอปพลิเคชัน GitHub ใน Slack ได้ แต่ในช่องเป้าหมาย

/github เข้าสู่ระบบ

สิ่งที่คุณต้องทำคือป้อนและทำตามคำแนะนำ ง่ายมาก.

GitHub Actions นั้นเร็วและง่ายกว่า

ฉันคิดว่าสิ่งนี้ขึ้นอยู่กับสิ่งที่คุณต้องการทำกับ CI/CD และอาจเป็นความชอบของคุณ แต่ฉันรู้สึกว่า GitHub Actions สร้างได้ง่ายกว่า GitLabCI ฉันคิดว่าสาเหตุหลักมาจากจำนวนผู้ใช้จำนวนมากและการมีอยู่ของ MarketPlace มีการกระทำทั่วไปส่วนใหญ่ และคุณสามารถค้นหาวิธีการทำได้โดยใช้กูเกิล GitLab CI รู้สึกเหมือนเขียนสคริปต์ แต่ GitHub Actions ให้ความรู้สึกเหมือนเรียกใช้ Action และดำเนินการ

แอพสมาร์ทโฟนที่สะดวก

สิ่งนี้เป็นสิ่งที่คาดไม่ถึงจนกว่าคุณจะลอง แต่มันสะดวกมาก โดยเฉพาะอย่างยิ่งเกี่ยวกับการรับรองความถูกต้อง การรับรองความถูกต้องด้วยสองปัจจัยนั้นลำบากเกินไปหากไม่มีแอพ ดังนั้นฉันจึงปล่อยมันไปไม่ได้ นอกจากนี้ นี่คือวิธีการใช้เป็นผู้วิจารณ์ แต่ด้วยแอป GitHub คุณสามารถเขียนรีวิวด้วยวิธีใดวิธีหนึ่ง GitLab ไม่มีแอปตั้งแต่แรก ดังนั้นคุณจึงดูได้เฉพาะในเบราว์เซอร์ แต่ใช้งานกับสมาร์ทโฟนค่อนข้างยาก ฉันเดินทางบ่อย ดังนั้นจึงสะดวกที่จะตรวจสอบสิ่งต่างๆ บนสมาร์ทโฟนในเวลาเร่งรีบ แต่ฉันเลิกใช้ GitLab แอป GitHub อาจไม่สะดวกสบายเท่า แต่คุณสามารถตรวจสอบ แสดงความคิดเห็น และผสานได้ตามปกติ

จุดที่ไม่ดี

ตามที่คาดไว้ ฟังก์ชันการจัดการโครงการจะขึ้นเป็น GitLab

ไม่สามารถจัดกลุ่มที่เก็บ

สิ่งนี้ไม่สะดวก โดยเฉพาะอย่างยิ่งถ้าคุณต้องการแยกที่เก็บส่วนหน้าและส่วนหลัง แต่คุณต้องการจัดการให้เป็นโครงการเดียว ด้วยเหตุนี้ GitLab จึงสะดวกเพราะสามารถจัดกลุ่มที่เก็บข้อมูลและจัดการป้ายกำกับปัญหาและเหตุการณ์สำคัญในลักษณะที่ใช้ร่วมกันได้ นอกจากนี้ เนื่องจากไม่มีการจัดกลุ่ม จึงเป็นไปไม่ได้ที่จะมีป้ายกำกับที่เหมือนกันสำหรับปัญหาภายในองค์กร คุณสามารถตั้งค่าป้ายกำกับเริ่มต้นในการตั้งค่าองค์กร แต่นี่เป็นเพียงป้ายกำกับเริ่มต้นเมื่อสร้างที่เก็บ ดังนั้นหากคุณต้องการเพิ่มป้ายกำกับนี้สำหรับทั้งองค์กร คุณจะเพิ่มทั้งหมดพร้อมกันไม่ได้

การจัดการบอร์ด (คัมบัง) ไม่สามารถทำได้ด้วยปัญหาเพียงอย่างเดียว

GitLab สามารถตั้งค่า DueDates และ Milestones ใน Issues ได้เองและจัดการพวกมันในมุมมองบอร์ด แต่ GitHub ไม่มีฟีเจอร์นั้นใน Issues แต่มีฟีเจอร์ที่เรียกว่า Project และเป็นกลไกที่สามารถจัดการได้โดยการเชื่อมโยง Project และ Repository
ตอนแรกฉันคิดว่าสิ่งนี้จะมีประโยชน์เพราะช่วยให้คุณสามารถรวมที่เก็บหลาย ๆ อันได้ อย่างไรก็ตาม เมื่อคุณใช้มันจริง ๆ มันไม่สะดวกเลย ฉันคิดว่ามันเป็นปัญหาเกี่ยวกับโครงสร้าง UI แต่ GitHub ยังมีแง่มุมที่คุณไม่สามารถจัดการบอร์ดบนหน้าจอปัญหา และคุณไม่สามารถดำเนินการโดยละเอียดเกี่ยวกับปัญหาบนหน้าจอบอร์ดได้ ในฐานะผู้จัดการโครงการ ความรู้สึกของการดำเนินการอย่างละเอียดเป็นเรื่องที่เครียด

วิธีการย้ายจริง

จากนี้เราจะอธิบายถึงงานการย้ายข้อมูลจริง เป็นเรื่องง่ายที่จะย้ายซอร์สโค้ด แต่ปัญหาคือการย้ายปัญหาและคำขอผสาน การโยกย้ายครั้งนี้https://github.com/piceaTech/node-gitlab-2-githubใช้เครื่องมือที่เรียกว่า มีการอธิบายการใช้งานไว้ค่อนข้างละเอียดใน README แต่ขั้นตอนหลักมีดังนี้

1. git โคลน node-gitlab-2-github
2. การติดตั้ง npm
3. มิเรอร์จากที่เก็บ GitLab ไปยังที่เก็บ GitHub
4. คัดลอก sample_settings.ts ไปยัง stings.ts
5. แก้ไข settins.ts
6. เริ่มทำงาน npm

สำหรับรายละเอียดเกี่ยวกับแต่ละวิธี โปรดดูที่ README ดังนั้นฉันจะละเว้นและอธิบายประเด็นสำคัญ

วิธีการย้ายข้อมูลนี้ไม่ได้ระบุถึงอะไร

เครื่องมือนี้สามารถย้ายปัญหาและ MergeRequests ได้ แต่ไม่ใช่ทั้งหมดที่จะย้ายได้อย่างสมบูรณ์แบบ ฉันคิดว่าทั้งหมดนั้นยอมรับได้ แต่ถ้าเนื้อหาต่อไปนี้ไม่เป็นที่ยอมรับ ก็จะไม่สามารถใช้วิธีการย้ายข้อมูลนี้ได้

คำขอผสานที่ไม่มีสาขาต้นทางไม่สามารถโอนย้ายไปยังคำขอดึงได้

หากมีสาขาต้นทาง คำขอผสานสามารถแปลงเป็นคำขอแบบดึงได้ แต่ถ้าสาขาต้นทางถูกตั้งค่าให้ลบเมื่อผสาน คำขอผสานที่ไม่มีสาขาต้นทางจะถูกแปลงเป็นปัญหาแทนคำขอแบบดึง ย้าย เมื่อย้ายแล้ว จะมีป้ายกำกับโดยอัตโนมัติว่าเป็นคำขอผสาน gitlab และเพิ่มไปยังปัญหาที่ปิดแล้ว

ไม่สามารถย้ายไฟล์แนบปัญหาและ MergeRequest

ไฟล์ที่แนบมาสามารถอัปโหลดไปยัง S3 ด้วยฟังก์ชันตัวเลือกของเครื่องมือ แต่เนื่องจากเครื่องมือนี้ไม่ได้แทนที่ URL ที่อ้างถึงไฟล์ แทนที่จะบันทึกไฟล์ที่แนบมาจาก GitLab ไปที่ S3 Just give it to me.

ไม่สามารถสืบทอดข้อมูลเจ้าของปัญหาได้

เจ้าของปัญหาจะเป็นบัญชีดำเนินการเมื่อย้ายข้อมูลครั้งนี้ พูดให้ชัดเจน คือชื่อบัญชีที่ตั้งไว้ในสคริปต์เมื่อดำเนินการ ดังนั้นฉันจึงไม่รู้ว่าใครคือผู้ออกปัญหาเมื่อออกใน GitLab เก็บไว้

ไม่สามารถย้ายปัญหาที่ไม่มีผู้ใช้เป้าหมายได้

หากไม่มีผู้ใช้ที่ตั้งค่าเป็นผู้รับมอบหมายหรือผู้ตรวจทานใน GitHub จะไม่สามารถย้ายปัญหาได้และจะเกิดข้อผิดพลาดขึ้น มากที่สุดเท่าที่จะเป็นไปได้ ควรมีบัญชีบน GitLab ต้นทางและ GitHub ปลายทาง

1. การเตรียมการ

รับบัญชี GitHub ของผู้ใช้ทั้งหมดที่คุณต้องการย้าย และทราบรหัสบัญชี GitHub ของพวกเขา คุณต้องสร้างองค์กร GitHub ด้วย มันไม่ยากที่จะสร้าง เมื่อคุณพร้อมแล้ว ขั้นแรกให้สร้างที่เก็บเพื่อย้ายไปยัง GitHub ตราบใดที่คุณมีพื้นที่เก็บข้อมูลที่จะโอนย้าย คุณสามารถปล่อยให้การตั้งค่าพื้นที่เก็บข้อมูลเป็นค่าเริ่มต้นได้ในขณะนี้ ถัดไปคือการสะท้อนไปยัง GitHub แต่นี่คือREADME เบื้องต้นแค่ทำตามที่หัวข้อบอก แล้วคุณจะสบายดี

2. แก้ไขรหัส

มันเป็น node-gitlab-2-github แต่มีปัญหา 3 อย่างกับโค้ดเหมือนเดิม ดังนั้นฉันจึงแก้ไขมันในเครื่องและจัดการกับมัน

เพิ่มเอาต์พุตข้อผิดพลาด

ตามที่เป็นอยู่ ฉันได้เพิ่มผลลัพธ์เนื่องจากฉันไม่ทราบสาเหตุที่ทำให้ไม่สามารถอัปโหลดไฟล์แนบได้

       กลับ Buffer.from (data, 'binary'); } catch (err) { + console.log(`err=${err}`) console.error (`ไม่สามารถดาวน์โหลดไฟล์แนบ #${relurl}.`); return โมฆะ;

สิ่งที่ต้องทำเมื่อป้ายกำกับซ้ำกันใน Group Label และ Project Label

ไม่ใช่เรื่องดีที่ป้ายกำกับจะซ้ำกันตั้งแต่แรก แต่น่าเสียดายที่ป้ายกำกับกลุ่มและป้ายกำกับโครงการซ้ำกัน อาจถูกสร้างขึ้นโดยไม่ได้ตั้งใจและไม่มีใครสังเกตเห็น แต่ในกรณีนี้เกิดข้อผิดพลาดขึ้นและไม่สามารถดำเนินการถ่ายโอนได้ ดังนั้นฉันจึงเพิ่มรหัสเพื่อบังคับการขจัดข้อมูลซ้ำซ้อน

       ถ้า (settings.conversion.useLowerCaseLabels) { labels = labels.map((el: string) => el.toLowerCase()); } + labels = Array.from(new Set(labels)) }

การติดต่อเมื่อมีภาษาญี่ปุ่นรวมอยู่ในไฟล์แนบ

ฉันคิดว่านี่เป็นเรื่องปกติ โดยเฉพาะอย่างยิ่งสำหรับภาพหน้าจอที่ติดปัญหาบั๊ก ชื่อไฟล์เริ่มต้นจะมีภาษาญี่ปุ่น ด้วยเหตุนี้ ฉันจึงแก้ไขเป็นการเข้ารหัส URL

   async getAttachment (relurl: สตริง) { ลอง { - const ไฟล์แนบUrl = this.host + '/' + this.projectPath + relurl; + const ไฟล์แนบUrl = encodeURI (this.host + '/' + this.projectPath + relurl); const ข้อมูล = (

3. แก้ไขและเรียกใช้ settings.ts

วิธีการแก้ไขจะหาข้อมูลสำหรับการตั้งค่าได้ที่ไหนใน READMEมีการอธิบายในรายละเอียดที่เขียนข้อมูล มีการอธิบายตำแหน่งของ AccessToken อย่างละเอียด ดังนั้นฉันไม่คิดว่าคุณจะหลงทาง เมื่อคุณพร้อมแล้ว ให้รัน npm run start และคุณจะเห็นผลลัพธ์ด้านล่าง

เริ่มการทำงาน $ npm > gitlab-2-github@0.1.5 เริ่มต้น > โหนด node_modules/ts-node/dist/bin.js ./src/index.ts =============== = =================== รายละเอียดการโอน ============================ = ===== ================================== การถ่ายโอนเหตุการณ์สำคัญ ======== = ========================= การสร้าง: การพัฒนาเบื้องต้นเสร็จสมบูรณ์ การสร้าง: การส่งมอบเสร็จสมบูรณ์ =============== = ================== การโอนป้ายกำกับ ============================= = ==== การสร้าง: การทำ การสร้าง: การปรับปรุง การสร้าง: กำลังตรวจสอบ การสร้าง: การทดสอบ การสร้าง: การทดสอบ การสร้าง: สิ่งที่ต้องทำ มีอยู่แล้ว: จุดบกพร่อง การสร้าง: การสนทนา มีอยู่แล้ว: เอกสาร มีอยู่แล้ว: ซ้ำ ~~ ======== ========================== การโอนเผยแพร่ ============ ========== ============ โอน 0 ออก =================================== กำลังโอน ประเด็น ================================== การโอน 141 ประเด็น การโอนย้าย ประเด็น #1 ('รายการบัญชี').. . กำลังย้ายความคิดเห็นเกี่ยวกับปัญหา... ...สร้างความคิดเห็นเสร็จแล้ว (ย้ายข้อมูล 11 ความคิดเห็น ข้ามไป 3 ความคิดเห็น) ...เสร็จสิ้น กำลังย้ายปัญหา #1 ~~~ สร้างปัญหาเรียบร้อยแล้ว สถิติ: จำนวนปัญหาทั้งหมด: 141 Nr. ของการใช้งาน ปัญหาตัวยึดตำแหน่ง: 0 จำนวนของปัญหาการแทนที่ที่ใช้แล้ว: 0 จำนวนของปัญหาการย้ายข้อมูลล้มเหลว: 0 ========== ==================== ==== การถ่ายโอนคำขอผสาน =================================== การถ่ายโอนคำขอรวม 218 รายการ การสร้างคำขอดึง: ! 1 - คำขอดึง #1 (ไม่มีสาขาต้นทาง 'sugano/basic_structure' => ไม่สามารถย้ายคำขอดึง สร้างปัญหาแทน กำลังย้ายความคิดเห็นคำขอดึง... ...สร้างความคิดเห็นเสร็จแล้ว (ย้ายความคิดเห็น 24 รายการ ข้ามความคิดเห็น 3 รายการ) คำขอ #218 (ไม่มีสาขาต้นทาง 'sugano/update_perpage' => ไม่สามารถย้ายคำขอดึงได้ สร้างปัญหาแทน กำลังย้ายความคิดเห็นคำขอดึงข้อมูล... ...สร้างความคิดเห็นเสร็จแล้ว (ย้ายข้อมูล 3 ความคิดเห็น ข้ามไป 0 ความคิดเห็น) โอนเสร็จสมบูรณ์!

โดยวิธีการที่ใช้เวลานานในการวิ่ง แม้ว่าจะขึ้นอยู่กับจำนวนของปัญหาและคำขอดึง แต่ทั้งหมด 500 เคสก็ใช้เวลาประมาณหนึ่งชั่วโมง

4. เขียนใหม่จาก GitLabCI เป็น GItHub Actions

ตอนนี้การย้ายที่เก็บเสร็จสมบูรณ์แล้ว ไม่ใช่เรื่องใหญ่หากจบลงด้วยข้างต้น การย้ายข้อมูลที่ยุ่งยากที่สุดคือการย้ายข้อมูล CI/CD

ในขณะนี้ GitHub จะอธิบายวิธีการย้ายจาก GitLab Ci ไปยัง GitHub Actions

https://docs.github.com/ja/actions/migrating-to-github-actions/migrating-from-gitlab-cicd-to-github-actions

อย่างไรก็ตาม ในความคิดของฉัน การเรียนรู้วิธีเขียน GitHubActions และเขียนใหม่ตั้งแต่ต้น แทนที่จะแปลงวิธีคำอธิบายเพียงอย่างเดียวจะดีกว่า GitLab CI และ GitHub Actions มีวิธีคิดและรูปแบบที่แตกต่างกัน ดังนั้นหากคุณเขียนในรูปแบบการย้ายข้อมูล คุณจะถูกลากโดยสไตล์ของ GitLab และความดีของ GitHub Actions ก็จะจางหายไป

หากคุณเขียน GitLab CI คุณสามารถใช้ GitHub Actions ได้อย่างง่ายดายหากคุณคำนึงถึงสิ่งต่อไปนี้

สรุป

คันโนะ

มันเป็นอย่างไร? สำหรับผู้ที่กำลังคิดที่จะย้ายจาก GitLab และผู้ที่สงสัยว่าจะย้ายจาก Bitbucket อันไหนดี ฯลฯ ฉันจะขอบคุณมากถ้าคุณสามารถช่วยฉันได้

โดยส่วนตัวแล้ว ผมใช้ GitLab มานาน จึงชินและผูกพันกับมัน ที่ San-El เราตั้งอยู่ในพื้นที่ชนบท แต่เราต้องการอุทิศตนต่อไปเพื่อไม่ลดเสาะหาเทคโนโลยี

สุดท้าย เราสรุปคำแนะนำของเราสำหรับแต่ละกรณี