[NCCUCS] Gitlab 歷次討論紀錄

2012-2-13 討論整理

應了解部分

• Capistrano ：RoR 自動佈署，以及佈署不順利時，自動 Rollback 到無問題的前次版本

  • 這個工具是為了日後升級如果出問題可以還原，升級也比較可以自動

• 尋找 Gitlab 中的 fork 功能

  • 改變原本的模式：現在助教手動或在系統功能完成後，用系統功能開啟作業 Repo
  • 接著學生各組或個人去 fork 助教的原始作業 Repo ，進而再使用 branch 等 Git 功能
  • 團體作業一定會要求要開 branch ，以及要使用 merge 等相關協做功能
  • 作業完成後，向助教的原始 Repo 發出 Merge Request ，聲明作業已經完成。此點見以下描述

• 尋找是否 Gitlab 有類似 GitHub ，Merge Request 的功能

  • Merge Request 雖然原本是做 fork 的兩項計畫某時間點合併功能，但也可以作為作業繳交的方式
  • 學生都從助教的原始作業 Repo fork 出自己的 Repo ，繳交時使用提出 Merge Request 的方式繳交
  • 學生先發出 Merge Request 代表作業已經完成，然後助教所在的 Project 收到這個訊息
  • 這樣做的好處是 Merge Request 可以開啟討論機制：助教可以針對所欲 merge 的作業做出批改與評論的動作，放在該功能的討論串中
  • 當然，若是繳交的作業根本無法編譯過，或嚴重不合要求，應當成該學生的 Repo Issue

• 尋找相似於 GitHub 中，Organization 的功能

  • Organization 是指參與者不是以個人在 GitHub 上為單位，而是以一個團隊為主
  • 這包括 email 通知、相關帳號、權限等可以此為單位，因此適合上課學生的帳號對應功能等

其他議題

• 作業打包下載，因為時間可能會比較久，所以應該使用 email 系統在該批次功能完成後通知使用者。而不是讓網頁 Timeout
• Gitlab instance 備份等系統相關問題
• 學生端 Git 是否要開發 client 版本的 script ，協助分析與上傳功能
• 比目前 Gitlab 上的討論機制，更好的討論方式
• Jenikns 的 CI serve 結合問題
• 目前先集中在尋找或開發 fork 與 merge request 兩個功能上。因為這對作業繳交流程至關重要