如何使用 GitHub Actions 構建自己的 CI/CD 管道

在本教程中，您將學習如何直接從 GitHub 上的存儲庫中使用 GitHub Actions 構建自己的持續集成/持續交付 (CI/CD) 管道。

以下是關於使用 GitHub Actions 作為首選 CI/CD 工具的優勢以及如何使用它構建 CI/CD 管道的快速指南。

持續集成/持續交付 (CI/CD) 長期以來一直是——並將繼續是——DevOps 專家的領域。但隨著 2019 年通過 GitHub Actions 將原生 CI/CD 引入 GitHub，將 CI/CD 直接從存儲庫直接引入工作流程比以往任何時候都容易。

這是一件很棒的事情。作為開發人員，我們接受過使用同行評審來確保我們的代碼有效的培訓。但我在這裡告訴你，我們需要破壞同行評審。如果您使用 Git、GitHub 和 GitHub Actions 構建 CI/CD 管道，您應該對自己的代碼充滿信心。

我將直接從您在 GitHub 上的存儲庫中向您詳細介紹如何構建您自己的 CI/CD 管道。

將 GitHub Actions 用於 CI/CD 管道的主要優勢

但首先，讓我們談談使用 GitHub Actions 的一些好處——因為老實說，還有很多其他工具。讓我解開我遇到的四大好處：

• CI/CD 管道設置很簡單：GitHub Actions 由開發人員製作並為開發人員製作，因此您不需要專門的資源來設置和維護您的管道。無需手動配置和設置 CI/CD。您不必設置 webhook，您不必購買硬件、保留一些實例、保持最新狀態、打安全補丁，或者關閉閒置的機器。您只需將一個文件放入您的存儲庫中，它就可以工作。
• 響應 GitHub 上的任何 webhook：由於 GitHub Actions 與 GitHub 完全集成，您可以將任何 webhook 設置為自動化或 CI/CD 管道的事件觸發器。這包括諸如拉取請求、問題和評論之類的內容，但它還包括來自您已集成到 GitHub 存儲庫中的任何應用程序的 webhook。假設您將使用現有的眾多工具中的任何一種來運行您的開發管道的一部分。使用 GitHub Actions，您可以從這些應用程序觸發 CI/CD 工作流和 webhook 管道（當然，如果您已將聊天應用程序集成到 GitHub 存儲庫中，即使是簡單的事情，例如聊天應用程序消息）。
• 社區支持、可重用的工作流程：您可以與更廣泛的 GitHub 社區公開分享您的工作流程，或訪問GitHub Marketplace中預先構建的 CI/CD 工作流程（有超過 11,000 個可用操作！）。我有沒有提到每一個動作都可以通過引用它的名字來重用？是的，那也是。
• 支持任何平台、任何語言和任何云：GitHub Actions 與平台、語言和云無關。這意味著您可以將它與您選擇的任何技術一起使用。

如何使用 GitHub Actions 構建 CI/CD 管道

在我們深入研究之前，這裡有一些簡短的說明：

• 清楚 CI/CD 管道是什麼以及應該做什麼。這是一個簡單的註釋，但很重要。CI 管道在代碼更改時運行，並應確保您的所有更改在集成後與其餘代碼一起工作。它還應該編譯您的代碼、運行測試並檢查它是否正常工作。CD 管道更進一步，將構建的代碼部署到生產環境中。
• GitHub Actions 採用“選擇你自己的冒險”類型的 CI/CD 方法。第一次在存儲庫中打開 GitHub Actions 時會看到它。根據您的技術要求，您可以利用許多帶有預建 CI 工作流程的指導選項。但如果您願意，您也可以從頭開始構建自己的 CI 工作流程。
• 我們的示例具有一個基於 Astro 構建並通過 GitHub Pages 部署的網站。對於本指南的 CI 和 CD 部分，我們將使用我構建和開發的名為www.opensauced.pizza的網站。該網站旨在使首次開源貢獻者更容易找到要從事的開源項目，並通過明確的入職流程確定項目的優先級。
• 如果您是視覺學習者，我們可以滿足您的要求。雖然我將引導您使用我的 GitHub 項目www.opensauced.pizza構建一個簡單的 CI/CD 管道，但您也可以觀看一個視頻，我將這些步驟付諸實踐，並為我的另一個項目構建一個快速的 CI 流程: hot.opensauced.pizza。

好的，讓我們這樣做。

第 1 步：創建或選擇一個存儲庫，然後選擇一個項目

這聽起來很基礎，但使用 GitHub Actions 構建 CI 管道的第一步是在 GitHub 上創建或選擇存儲庫。您可以使用現有的項目代碼庫，在 GitHub 上創建您喜歡的項目，或者從頭開始。

為簡單起見，我將在我的 Open Sauced 項目中使用Open Sauced 存儲庫。隨意通過分叉這個存儲庫並使用分叉貢獻來仔細查看。

www.opensauced.pizza的屏幕截圖，這是我們正在為 CI 管道構建的網站。

可以看到 Open Sauced 存儲庫比較簡單。該網站本身使用OneGraph 製作，託管在Netlify上，並使用 HTML、CSS 和 JavaScript 構建。我還利用Storybook進行 UI 和設計工作。我們還使用 React 和 npm 進行包管理、安裝和測試——稍後會詳細介紹。

第 2 步：在您的存儲庫中打開 GitHub Actions 以開始構建您的 CI/CD 工作流

要開始構建 CI/CD 管道，請打開存儲庫頂部導航欄中的 GitHub 操作選項卡。

您應該會看到與您的項目使用的技術相匹配的 CI/CD 和工作流自動化模板列表（旁注：我們剛剛改進了整個用戶流程。如果您有興趣，請稍後查看詳細信息）。

對於這個項目，我們將利用幾個不同的 CI/CD 工作流來測試、構建、暫存和部署我們的代碼。這些包括：

• 開發工作流程：每當打開、編輯、同步或重新打開拉取請求時，此工作流程都會運行幾個不同的作業。這些作業包括設置 Node、安裝 npm 包和依賴項、運行 npm 測試以及循環執行許多 lint 作業（設置節點、安裝 npm@latest、安裝依賴項、lint 代碼……你明白了）。
• CodeQL 分析工作流程：此工作流程在我們將代碼合併到主分支後對我們的代碼運行一系列 CodeQL 安全測試，以確保沒有已知漏洞。自己查看 YAML 文件。它超級簡單，但很有效，我強烈推薦。
• 發布和構建工作流程：此工作流程在將代碼更改發佈到 Docker 並構建應用程序後運行測試並強制執行 lint。它還將最終代碼部署到我們的生產環境中，使用與自動發布說明類似的結構來剪切發布，將站點捆綁到一個容器中並發佈到 ghcr。從那裡，它會影響存儲庫中的版本號和標籤。這是我們正在運行的更複雜的工作流程之一，我在某種程度上對其進行了過度簡化，但您可以自己查看工作流程中發生的工作和步驟。
• 故事書部署工作流程：此工作流程通過我們的前端 UI 技術故事書將任何 UI 組件更改部署到我們的生產網站。

這些就是我們的工作流程。這裡的重點是，如果您正在處理一個單獨的項目或一些小型項目，那麼構建 CI 管道不一定是一個令人生畏的過程。您可以從一些簡單的事情開始（如上面突出顯示的內容），以使您的工作流程更輕鬆一些。

如果您正在構建企業軟件、維護大型開源項目或與大型團隊合作處理任何事情，CI/CD 管道可以而且應該比這更複雜。但是，如果您剛剛開始，請不要擔心讓您的 CI/CD 管道滿足大型團隊或雄心勃勃的項目的每一個需求——只要讓它適合您。

第 3 步：更改代碼以觸發 CI/CD 管道

為了這個練習，我們將對網站標題（“你的下一個開源貢獻的路徑”）做一個小的改動，在末尾添加“還有更多的披薩”。最終結果將如下所示：“通往下一個開源貢獻和更多披薩的道路。”

讓我們開始工作吧。

打開 src 文件夾，然後轉到 components 子文件夾。從那裡，您將要打開 hero.js 文件。在該文件中，轉到以下代碼：

<div>
<h1>The path to your next</h1>
<h2>Open Source</h2>
<h1>contribution.</h1>
</div>

通過添加“和更多披薩”來更改副本。它應該如下所示：

<h1>The path to your next</h1>
<h2>Open Source</h2>
<h1>contribution and more pizza.</h1>

第 4 步：查看工作流可視化工具和實時日誌，全面了解管道的運行情況

推動上述更改後，您將進入有趣的部分：使用工作流可視化工具和實時日誌實時查看您的管道工作。

好吧，也許這不是最有趣的部分，但是知道如何使用這兩種工具……稍後你會感謝我的。

讓我們先回顧一下工作流可視化器。可通過 Actions 主頁訪問，可以通過選擇您想要查看的任何工作流來調出工作流可視化工具。你會發現這樣的東西：

用於自動部署工作流的工作流可視化工具的屏幕截圖

在這裡，您可以看到給定工作流程中的哪個作業在何時發生，以及它們是否正在工作，帶有一個綠色的小複選標記，一個黃色標誌表示某項工作是否正常，一個紅色標誌表示某項工作是否失敗。

這是您的 YAML 工作流程，但採用可視化形式，它可以更輕鬆地查看正在發生的事情以及它是否在工作。

專業提示：由於工作流可視化圖形採用顏色編碼，可快速顯示成功的操作、正在進行的操作以及在特定步驟失敗的操作，因此請在設置新的工作流並首次觸發後嘗試使用它。

現在，關於實時日誌，您應該了解以下內容：首先，他們是您最好的朋友（說真的）。實時日誌非常有用，可以準確地確定什麼在工作，什麼是壞的，以及為什麼你認為應該工作的事情根本不工作。但更重要的是，您可以瀏覽這些日誌並查看時間戳、原始日誌，甚至下載日誌本身以供本地參考。

可以通過存儲庫中的“操作”菜單直接訪問實時日誌，並單擊任何作業或工作流。如果您在構建 CI/CD 管道時所做的一切都是正確的，那麼您可能不需要查看實時日誌。

但是如果出現問題，這些實時日誌可以非常有助於參考。無論您是查看時間戳還是流程的哪個部分失敗，您都可以確定如何解決問題。

專業提示：如果您正在調試對時間敏感的錯誤，時間戳會非常有用。默認情況下，實時日誌將對哪​​些作業失敗以及在給定工作流程中的時間進行顏色標記，這樣可以更輕鬆地立即解決問題。

隨身攜帶

無論您是在從事開源項目、副項目還是工作項目，採用 CI/CD 都有一些很大的好處——比如產生更一致和可行的版本。但最大的好處是相信您的代碼在將其合併到您的主分支、測試並部署後可以正常工作。

使用 GitHub Actions，構建 CI/CD 管道是一個簡單的過程，它可以讓您更廣泛地專注於您的代碼，而不是緊隨其後的所有事情。你有任何問題嗎？

文章原文來源https://github.blog

#github #githubactions #devops

What is GEEK

Buddha Community

Working with GitHub Actions

GitHub has become one of the most widely used Source Code Repository. Its Distributed Version Control System helps the developers for faster development and Integration of their code. Recently, it launched GitHub Actions in beta which enabled developers to create automated workflows to build, test, and deploy their source code on GitHub.

In this article, we will discuss about GitHub Actions and how it can be used to build an automated software development life-cycle workflow.

Below are the things we will discuss in this article:

• About GitHub Actions
• Basic Concepts of GitHub Actions
• Demo on Using GitHub Actions
• Creating a workflow file
• Configuring the workflow file
• Running the workflow file
• Conclusion

About GitHub Actions

Using GitHub Actions, we can create custom workflows that will help to build, test, package, release or deploy the code without leaving the GitHub UI. It enables us to build Continuous integration and Continuous Deployment capabilities directly in our repository. Here are some important features about GitHub Actions.

**YAML based process: **The workflow is written in YAML. Hence it is easy to create, read and use the actions that make up the workflow.

**One Place for everything: **By using GitHub Actions, we can build and test the developed code directly in our repository. There is no need to worry about integrating the source code repository with other build and deployment tools. Everything can be done in one single place.

**Easy to integrate code: **Since enabling CI/CD directly in the repository is possible using workflows, creating merge requests(MRs), building, testing and integrating them become way more seamless.

#tech (re)view #build #cd #ci #ci-cd #github #github actions #gitlab-ci #gradle #java #test

Serverless CI/CD on the AWS Cloud

CI/CD pipelines have long played a major role in speeding up the development and deployment of cloud-native apps. Cloud services like AWS lend themselves to more agile deployment through the services they offer as well as approaches such as Infrastructure as Code. There is no shortage of tools to help you manage your CI/CD pipeline as well.

While the majority of development teams have streamlined their pipelines to take full advantage of cloud-native features, there is still so much that can be done to refine CI/CD even further. The entire pipeline can now be built as code and managed either via Git as a single source of truth or by using visual tools to help guide the process.

The entire process can be fully automated. Even better, it can be made serverless, which allows the CI/CD pipeline to operate with immense efficiency. Git branches can even be utilized as a base for multiple pipelines. Thanks to the three tools from Amazon; AWS CodeCommit, AWS CodeBuild, and AWS CodeDeploy, serverless CI/CD on the AWS cloud is now easy to set up.

#aws #aws codebuild #aws codecommit #aws codedeploy #cd #cd pipeline #ci #ci/cd processes #ci/cd workflow #serverless

GitHub Demo Days - Using GitHub Actions for testing cloud native applications

What makes a project successful? For developers building cloud-native applications, successful projects thrive on transparent, consistent, and rigorous collaboration. That collaboration is one of the reasons that many open source projects, like Docker containers and Kubernetes, grow to become standards for how we build, deliver, and operate software. Our Open Source Guides and Introduction to innersourcing are great first steps to setting up and encouraging these best practices in your own projects.

However, a common challenge that application developers face is manually testing against inconsistent environments. Accurately testing Kubernetes applications can differ from one developer’s environment to another, and implementing a rigorous and consistent environment for end-to-end testing isn’t easy. It can also be very time consuming to spin up and down Kubernetes clusters. The inconsistencies between environments and the time required to spin up new Kubernetes clusters can negatively impact the speed and quality of cloud-native applications.

Building a transparent CI process

On GitHub, integration and testing becomes a little easier by combining GitHub Actions with open source tools. You can treat Actions as the native continuous integration and continuous delivery (CI/CD) tool for your project, and customize your Actions workflow to include automation and validation as next steps.

Since Actions can be triggered based on nearly any GitHub event, it’s also possible to build in accountability for updating tests and fixing bugs. For example, when a developer creates a pull request, Actions status checks can automatically block the merge if the test fails.

Here are a few more examples:

#engineering #enterprise #events #open source #actions #ci/cd #cloud native applications #cloud native architecture #devops #devops ci/cd #github actions #kubernetes #open source

A better logs experience with GitHub Actions

It’s now even easier to review logs from your GitHub Actions workflow runs. We’ve introduced several improvements to make the experience more performant, precise, and pleasing to use.

Why these changes matter

When we think about successful automation, we aim to spend the least amount of time looking at what’s automated, so we can focus our attention on what’s relevant. But sometimes things don’t go as planned, and we are required to review what happened. That debugging process can be frustrating; that’s why we’re introducing a series of changes that will improve both performance and user experience:

• Simplified the layout structure
• Introduced a single and faster virtualized scrolling
• The search is now more responsive
• Better ANSI, 8-bit, and 24-bit color support
• URLs are now interactive
• A new full-screen view mode
• A refreshed UI that improves readability and overall interactions

#features #product #actions #ci/cd #github actions #github

CI/CD with Vue, Firebase Hosting and Github Actions

Even if you’re the only developer in a project, you still have to make sure you automate your deployment process and follow certain steps in order to prevent bugs sneak into production code. Writing tests is the first step of it. But then, running those tests everytime you make a change in the code is a time consuming process where you can benefit from some automation.

This is where Github Actions come into play: How about creating a workflow in Github Actions which will run the tests for you when you make a pull request and won’t allow merging to master and deploying to production if the tests fail? That would really help with avoiding unintentional deployment of buggy code. Another important point is not forgetting to deploy your code into production when a pull request is merged to master. The Github workflow that we are going to create will also handle that by automatically deploying to Firebase Hosting when a pull request is completed.

Let’s see how it’s done step by step:

Creating a Vue Project

First of all, make sure your Vue CLI is up-to-date. As of this writing, the latest version is 4.5.8. You can check your current installment with this terminal command: vue --version .

If you have an older version, you can update by npm update -g @vue/cli or if you never had installed before you can install it globally by npm install -g @vue/cli.

Next, let’s create a brand new vue project called “vue_ci_cd” with the command vue create vue_ci_cd_example.

Not all settings are relevant for the purpose of this tutorial, but make sure the following settings are handled as follows:

• Please pick a preset: Manually select features
• Pick a unit testing solution: Jest
• Pick an E2E testing solution: Cypress (Chrome only)

It will then install all the necessary dependencies for the app. If everything goes well, you should be able to run the app with this command cd vue_ci_cd_example && npm run serve .

#firebase #github #vuejs #ci-cd-pipeline #github-actions