實驗在 GitLab Merge Request 之 CI Pipeline 中使用 CodeGPT 提供 Code review 建議

2023 年,ChatGPT 與 OpenAI 議題大熱門,全球都在探討可以將它們運用在哪些工作領域中,當然軟體開發工程師也不例外,舉凡寫程式、程式碼重構、產生 Commit messages、code review、pair programming、寫測試⋯⋯,幾乎每一個動作都有人在嘗試結合這波「AI」熱潮,希望讓這些任務能做得又快又好。 最近剛好看見台灣知名的講師與開源專案貢獻者 AppleBoy 也投身在此議題,開發了名為 CodeGPT 的工具,不僅能用它來自動生成 Commit 總結,甚至能做出 Code review 提供一些程式碼的改善建議。 按著 AppleBoy 的 CodeGPT 工具說明,我第一時間的想法即是,這樣的一個工具是不是適合放進 CI Pipeline 中呢?如果能讓隨著 Merge request (或 Pull request) 而執行的 CI Pipeline 能自動產生一份由 GPT 提供的 Code review 程式碼改善建議,這樣我們就可以自動額外獲得一份來自「非真人觀點」的 Code review 建議;即便這些「非真人的觀點」不一定正確或準確(因為 GPT 已被證實有時會一本正經的說瞎話),但它的建議依然有機會幫助真人跳脫自己固有的觀點,以不同的角度思考同一個問題。 以下我們就搶先試驗,試著將 CodeGPT 放進 GitLab Merge request CI Pipeline 吧! (本文初版撰寫於 2023.04.02,於 2023.04.04 更新。本文使用的 CodeGPT 版本為 v0.1.5,當你閱讀本文時,很可能 CodeGPT 已經改版與本文下述的操作步驟不同,還請自行關注各工具的最新異動資訊。) 操作步驟 下面我們就用一個最輕鬆的方式,來做出一個 Merge request 之 CI Pipeline,來實驗 CodeGPT。既然是最輕鬆的方式,所以我就直接在 gitlab....

April 2, 2023 · Cheng Wei Chen

iThome Cloud Summit 2022 - Lab: GitOps with GtLab and K8s

這是一篇留在草稿區很久的文章草稿,本來應該在 2022 年 7 月把它寫出來,但一拖稿,就無限延後了,趁著春節休假期間,終於有時間將它整理為一篇「堪用」的文章。 前言 感謝 iThome 的邀請,2022 年能有機會再次擔任 iThome Cloud Summit 的講師,負責一場分享一場 Hands-on Lab。 由於 2021 ~ 2022 年,個人並沒有玩太多新鮮的雲端新工具,因此最後還是決定以 GitOps 為題來準備這場 Hands-on Lab。但畢竟我在 2020 年就已經分享過一次 GitOps,總不能直接拿老東西出來分享,因此這次特別針對內容做了調整,試著將 Kubernetes(K8s)放進 Lab 的內容中。 在 2020 年時分享的 Hands-on Lab 是以 GitOps with GitLab 為題,主要是以 GitLab 的 CI/CD Pipeline,搭配 GitLab 當時仍在 beta 階段的 Terraform 相關功能,讓學員運用 GitLab Runner 透過 CI/CD Pipeline 可以彼此 Tirgger 的方式來實現 GitOps 的概念;當時還跟 AWS 合作索取了一些試用額度,讓 Lab 學員可以用 GitOps 的方式,在 AWS 建立 Ec2 並部署 Application。...

January 22, 2023 · Cheng Wei Chen

在 GitLab CI 中使用 Google osv-scanner

(本文首次發佈於 2023-01-01,於 2023-10-24 更新。) 根據 iThome 的報導,Google 釋出了一個新的免費開源軟體漏洞掃描工具 OSV-Scanner,可以幫助開發者自動掃描找出專案內的相依套件是否存有漏洞。看見這樣的好工具,我們第一時間當然要問一句,這玩意能夠放進我們的 CI Pipeline 嗎?是否能有助於我們及早發現程式碼中潛藏的資安問題呢? 因此本文,就讓我們試著在 GitLab CI Pipeline 中運用 OSV-Scanner 吧! 操作步驟 尋找可用的 Docker Image 老樣子,想要在 GitLab CI Pipeline 中試用一個新工具的第一步,當然是先找找看有沒有現成的 Docker image 可以使用。 在 2023/10/24 於 Docker Hub 上搜尋「osv-scanner」,目前都只能找到非 Google 官方建立的 Docker Image。 (截圖時間:2023/01/01) 不知為何這些 Docker Image 看起來都沒什麼人 Download 使用,稍微深入瀏覽後,可以發現只有 anmalkov/osv-scanner 的說明較完整,有興趣者可以嘗試看看。 以 anmalkov/osv-scanner 為例,我用它來嘗試掃描了手邊的一個專案,得到如下圖的結果,它依據 package-lock.json 的資訊,幫我找出許多的 Vulnerabilities,並且每一個 Vulnerability 都會提供一個 OSV URL,讓我可以了解更多的詳細資訊。 OSV URL 的網頁內容如下,會有完整的漏洞說明。 如果你想要自己 Build 一個 Image,則可以參考 GitHub Repo - osv-scanner ,在 Repo 中有提供 Dockerfile ,可以用來 Build image。...

January 1, 2023 · Cheng Wei Chen

《和艦長一起30天玩轉GitLab》第二版上市

辛苦了一整年(!?)終於在 2022 年底,將《和艦長一起30天玩轉GitLab》改版完成。這次也是走一個拖稿拖稿再拖稿的路線。好在出版社編輯沒有真的殺到我家樓下來堵我,畢竟都已經進行到排版二校時,我還一直試圖要塞入新的內容,實在是感謝他們的一再寬容。 除了感謝出版社,這次還要特別感謝三位朋友幫忙撰寫推薦序,以及家人們一再的包容與支持,二版新增的一小段致謝,就原汁原味的全文刊登如下。 2022 第二版致謝 隨著 GitLab 的迭代更新,我一直希望能有機會將本書改版更新,終於這份期望得以在 2022 年底實現。感謝在這段改版寫書過程中,提供我各種協助的各方好手——感謝願意推薦本書的社群前輩 William 及 Rick,你們豐富的知識與經驗一直是我努力學習的標竿;感謝同為 GitLab Hero 的墨嗓,你是我在專研 GitLab 之路上不可多得的好夥伴;感謝在 GitLab Taipei User Group 及 DevOps Taiwan Community 認識的多位社群朋友,彼此經驗交流、教學相長,讓社群能持續的成長茁壯。 最後,再次感謝我親愛的家人,感謝你們體諒並陪伴我每一次的寫稿生活,本書誕生的每一字一句都是你們的功勞。 其實在 2020 年《和艦長一起30天玩轉GitLab》初版上市時,我就已建立了 https://gitlab-book.tw 網站,在網站上提供最新的書籍內容勘誤,並一度想要將該網站轉化成為 GitLab 相關新知的分享平台,沒意外的話,明年會再次嘗試活化 gitlab-book.tw,看看可以如何讓網站能產生更多的價值。 2022/12/31 更新 由於 GitLab 實在是改版快速,因此我也會視狀況在 https://gitlab-book.tw 上更新一些書籍內容;像是 GitLab 15.7 推出後,在 gitlab.com 上就直接啟用新版的 Web IDE (VS Code),導致我在書中經常提到的 File Templates 功能目前是暫時無法使用的,為了因應這個狀況,我就有在 gitlab-book.tw 網站上提供對應的內容更新。 最後,還是厚臉皮的來一段工商服務,如果你問我自己最喜歡《和艦長一起30天玩轉GitLab》第二版的哪些內容?我會推薦第五章「實作 CI/CD Pipeline」。這個章節是我將自己過去的職場工作、CI/CD Pipeline 工作坊及對外開課所獲得的各種經驗,再次整理後重新撰寫的;希望能讓這本 GitLab 專書,不只有 GitLab 功能面的內容,也可以有更多跳脫單一工具、有助於大家實踐 CI/CD Pipeline 的經驗分享。如果你也正在擔任 CI/CD Pipeline 水管工人,推薦你一定要讀第五章,也歡迎與我交流分享你的經驗喔!...

December 30, 2022 · Cheng Wei Chen

iThome 鐵人賽(2022) - 重新認識 devops

隨著這些年參與社群活動,與各方高手交流,一直以來都很想以「DevOps」本身為題,留下些文字。 但總是以最近很忙、沒時間沈澱內容為藉口,一再拖延。 今年依然是忙到炸了,於是在頭被門夾到般神智不清的狀況下,決定就讓它更忙吧! 上面是我在今年參加「iThome 鐵人賽(2022)」時,於第一篇文章 Day 0 留下的文字,就如這段文字所述,一直以來都想要以「DevOps」為題,寫一些長篇系列文或科普文,但總是以「忙碌」為藉口,最終沒能有所產出。 這麼多年過去,今年終於忍不住了,我一定要寫,讓我寫,就算是用亂聊的方式,我也一定要寫些什麼,於是就誕生了這次的鐵人 30 篇文章。 這次參賽的主題為「重新認識 devops」,在系列文標題上,我故意使用小寫的「devops」,而不是當今常見的「DevOps」,不知道是否有人知道我的用意為何?這裡就先賣個關子,如果有人知道答案,可以私下與我聯繫,如果有答對正確答案,就讓我贈送你一本《和艦長一起 30 天玩轉 GitLab》(第二版)吧!(正確答案就讓我留到公布今年鐵人賽得獎名單的那天,再更新於本文吧!) 更新:鐵人賽得獎名單已經公佈了,所以我也來公佈我為何會使用小寫的「devops」,而不是當今常見的「DevOps」。其實原因很簡單,算是想要區別 2009 年 devops 這個詞剛出現沒多久,在那一個年代還很單純的 devops,以及經過多年直到現在已經被添加了各種多方意見,甚至是大幅偏向談論技術與工具的 DevOps。不知道你是否也覺得不同年代談到 DevOps 其實談論的內容也是大不同呢?總之,故意使用 devops 與 DevOps 算是我自己一點小小的「表態」,因此你會看到在今年的鐵人賽文章中,有些地方我會故意使用 devops,但有些則特意使用 DevOps,不曉得大家是否有注意到這項差異呢?今年的鐵人賽,因為是走一個拉迪賽的路線,並沒有談到太多深入的內容,如果未來有機會及餘力,希望可以重新再來一次「重新認識 devops」,將更多想寫的內容都一一落成文字。 目前文章依然留存於「iT 邦幫忙」網站上,一樣就暫時不搬回這裡,僅以超連結的方式連結各篇文章: 系列文「重新認識 devops」的內容大致上可以分成幾個主軸。(但因為是走想到哪寫到哪的路線,所以你也可以按著 Day0 ~ Day30 的順序讀下去。) 一、這次花了很多篇幅在講古。 Day 0:起心動念 Day 1:DevOps 只是個 hashtag Day3:2009 至 2022 DevOps 議題發展趨勢(一) Day4:2009 至 2022 DevOps 議題發展趨勢(二) Day6:DevOps 講古(一) Day7:DevOps 講古(二) Day8:DevOps 講古(三) Day13:從歷史看 CI/CD Pipeline(一) Day14:從歷史看 CI/CD Pipeline(二) Day15:從歷史看 CI/CD Pipeline(三) Day16:從歷史看 CI/CD Pipeline(四) Day17:從歷史看 CI/CD Pipeline(五) Day18:從歷史看 CI/CD Pipeline(小結) 二、也談了一些 DevOps 常見的老議題...

November 26, 2022 · Cheng Wei Chen

跟著 GitLab Auto DevOps 學習 CI/CD Pipeline(四)

本文為系列文章《跟著 GitLab Auto DevOps 學習 CI/CD Pipeline》的第四篇,藉由逐一檢視並解析 GitLab Auto DevOps 背後的 Templates,讓我們一起跟著 GitLab Auto DevOps 學習 GitLab CI/CD Pipeline。 在上一篇文章,我們學習到 workflow: 可以幫助我們控制在哪些條件之下才需要產生 CI/CD Pipeline。這次我們則是要進入第一個 Template - Jobs/Build.gitlab-ci.yml,看看 Auto DevOps 是如何實現同一個 CI Build 卻能適用於不同的程式語言。 此系列文清單: 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline(一) 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline(二) 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline(三) 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline(四) Jobs/Build.gitlab-ci.yml 首先讓我們直搗黃龍,直接查看 Jobs/Build.gitlab-ci.yml 的內容。 # 下面的版本來自 2022/02/04 的 https://gitlab....

February 20, 2022 · Cheng Wei Chen

透過 GitLab CI + K6 進行小規模 Load Testing

在先前的文章,已分享過使用 JMeter 和 drill 進行小規模 Load Testing,今天延續同樣的主題,這次要使用另一個新興熱門的 Load Testing 工具 K6,試一試「如何透過 GitLab CI + K6 進行小規模 Load Testing」。 操作步驟 首先,K6 在 2021 年已經被 Grafana Labs 買下來了,但目前(2022/02/03)看來,K6 官網依然還維持原貌,沒有太大的變化,只是多掛上了 Grafana Labs 的 Logo。K6 有提供 Open Source 與 K6 Cloud 兩種方案,而本文將採用的是 Open Source 方案。 準備 GitLab Runner 老樣子,第一步我們要先預備合適的 GitLab CI 環境,應該不用再多做解釋,請先準備好能夠操控 Container 的 GitLab Runner,如果你不知該如何準備 Runner,又想要快速試一下本文的內容,那最簡單的做法是註冊一個 gitlab.com 帳號,然後建立新 Project 並使用官方提供的 Shared Runners。 準備 Docker image - K6 第二步,預備一個能夠運行 K6 的 Docker image。 這次很幸運,已經有現成的 Image 可以使用 loadimpact/k6...

February 3, 2022 · Cheng Wei Chen