Githubアクションを通して連続的な統合を構成する方法?

あなたがGitHubまたはオープンソースコミュニティに新しいならば、あなたはたぶんこの記事のタイトルで言及された用語の大部分に慣れていないでしょう.そのようなフレーズは、オープンソースプロジェクトに私の最初の貢献をすることを通して操縦するとき、私に非常に脅迫的に見えました.しかし、私はそれが表示されるように困難ではないことを保証しましょう.この記事では、Githubのアクションを通じてノードCIを構成し、最初に複雑に思えるGithubの問題をナビゲートする方法についていくつかのヒントを与えます.
重要な用語の意味を理解し始めましょう.

🔗 連続積分（CI）とは何か

大部分の大きなプロジェクト(主にオープンソース)では、いくつかの開発者と貢献者は異なった特徴を構築して、別々の問題を同時に解決することに取り組んでいます.個々のコードは別々にうまく動作しているかもしれませんが、プロジェクトにまとめてコンコードを中断させたり、コードを中断させたりするときに、しばしば競合を導入することができます.そのような状況を避けるために、連続的な統合(CI)の実践は、開発者が頻繁に、1日に数回、共有リポジトリにコードを統合するところで行われました.自動化されたビルドおよび自動化されたテストは、その後、各統合を確認することができます.

“Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.” - Martin Fowler, Chief Scientist, ThoughtWorks

定期的にコードを統合することの重要な利点の一つは、エラーをすばやく検出し、より簡単に見つけることができるということです.導入されたそれぞれの変化が典型的に小さいので、欠陥を導入した特定の変化を正確に指摘することは速やかに行われる.

📑 何がgithubアクションですか？

貢献者がプル要求をするとき、倉庫の管理者が実行する必要があるいくつかの組織タスクがあります.これらは、プル要求の見直し、いくつかのテストを実行し、変更がREPOのコードスタイルと一致しているかどうかをチェックします.
ワークフローは1つ以上のジョブで構成され、イベントによってスケジュールされたり、イベントが発生したりすることができます.
プロジェクトが大きく成長し、より多くの貢献者、問題、およびプルの要求を蓄積すると、それはそれを維持するためのより組織的努力が必要です.したがって、管理者は自然にこれらのタスクのほとんどを自動化したい.
Githubアクションでは、リポジトリに発生したイベントに応答して自動的に実行される一連のアクションを定義できます.

💻 Githubアクションから始める

すべてのGiTubリポジトリはActions 以下に示すタブ.

一度あなたはActions タブでは、いくつかのワークフローテンプレートが表示されます.代表的に、以下に示す4つのカテゴリーがある.提案されたワークフローを選択するか、プロジェクトで使用される技術スタックに基づいて1つを選択するために連続統合ワークフローにスクロールダウンできます.
適切なテンプレートを見つけたらSet up this workflow .

👩‍💻 ワークフローの設定

テンプレートを選択するには、.ymlファイルは/で作成されます.あなたのコードリポジトリのgithub/ワークフローディレクトリ.あらゆるGiTubアクションは、必要とします.YML(YAMLはマークアップ言語)ファイルです.YAMLは一般的に使用可能な人間に読めるデータ直列化言語ですconfiguration files そして、データが格納されるか、伝送されるアプリケーション.
今すぐあなたの要件に応じてワークフローをカスタマイズすることができます.
次の手順の実行を自動化するノードプロジェクトの例を取り上げましょう.

ノード依存関係のインストール

潜在的エラーのコードを解析するには、

変更がREPOのコードスタイルと一致することを確認してください

我々.YMLファイルはこのようになります.

このファイルステップの内容を理解してみましょう.

name: Node CI

on:
   push:
   pull_request:

jobs:
   build:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v2
       - name: Install dependencies
         run: npm install
       - name: Linter
         run: npm run lint
       - name: Prettier Format
         run: npm run format

name [ optional ]-ワークフローが何をしているかを記述するために使用する

on -ワークフローをトリガーするイベントを一覧表示します.この場合、誰かがリポジトリに直接コードをプッシュするか、またはプル要求がなされるとき、動作は引き起こされます.こちらがlist of all events ワークフローをトリガーできます.

Job -このセクションは、上記イベントに応じて実行されるアクションを定義するために使用されます.

ジョブの下にネストされたタスクの複数のシーケンスが存在することができます.各シーケンスは名前で定義され、この場合は“build”です.この名前は、ワークフローの名前と同じように任意です.

run -ジョブが実行するVMを指定します.我々はUbuntu上でこれを実行するが、また、WindowsまたはMac OSを選択することができます.

STEP -コードのビルドとテストの手順を定義します

用途:アクション/checkout@v2-この行は、ソースコードを仮想マシンにofficially maintained action called checkout . これにより、ローカルマシンのディレクトリで作業するときにコマンドラインからコードをテストする方法に似たコードでコマンドを実行できます.

USEキーワードを使用すると、アクションの任意の定義済みの設定を使用することができます

各ステップは、そのステップで実行されるコマンドを定義するために名前とrunキーワードを必要とします

この場合、依存関係をインストールし、コードを実行し、コードスタイルを強制するために3つの手順を定義しました.あなたのコードをテストするコマンドを自動化する手順をカスタマイズするだけで名前を入力し、コマンドを入力できます.

お済みです今、プロジェクトにプッシュするたびに、コマンドは自動的に起動します.

✅ ワークフローのテスト

GATHUB動作がどのように動作するかをテストするために、リポジトリにプル要求を行います.このようなものが表示され、新しいプッシュコードがすべてのチェックを通過したかどうかを示します.

チェックが失敗した場合は、Details ボタン.あなたは、正確に何が間違っていたかを確認することができますし、どのポイントで、以下に示すように.

今すぐ迅速に問題を修正し、更新されたコードをプッシュすることができます.緑の目盛りマークは、あなたのコードがCIでセットされるテストを通過することを示します.

📝 結論

私は、この記事の話題がもうあまりに脅迫的であるようでないことを望みます.あなたは、これより複雑な問題に遭遇するかもしれません、しかし、戦略は単純です.あなたが特定の問題があなたがする必要があることを理解しないならば、各々の期間を研究して、その意味を理解してください.したら、少しだけ良いが必要ですが、それを解決する方法を知っていないかを知っているブログ、ビデオ、またはチュートリアルでは、タスクに関連する検索してください.何かがまだ不透明であるならば、コメントを落とすことによってコミュニティに助けを求めるように躊躇しないでください.多くの場合よりも、誰かがあなたのクエリに戻ることを確認します.
私は、このブログが何らかの方法であなたを助けたことを望みます.他の質問がある場合は、以下のコメントを自由にドロップしてください.
幸運とハッピーコーディングのベスト!😃

追加リソース

https://docs.github.com/en/actions/learn-github-actions/introduction-to-github-actions