つまり、GitHub は、コードの取得、テストの実行など、CI/CD の多くの操作をアクションとして呼び出します。開発者は独自のアクションを作成するか、他の開発者が提供するアクションを使用することができ、CI/CD プロセス全体が複数のアクションの組み合わせ、つまり Github アクションになります。

2.2 ジェンキンス

Jenkins は、ソフトウェアプロジェクトの継続的なビルド、テスト、デプロイのワークフローを自動化するために Java で記述されたオープンソースの自動化サーバーです。

Jenkins は主にリッチプラグインを介して CI/CD を実装します. 下の図は、Github からコードを抽出し、コードから Docker イメージを構築し、それをテストして、さらにリモートリポジトリ DockerHub にプッシュする単純な Jenkins ワークフローを表しています。

2.3 Github アクションと Jenkins の比較

Jenkins と GitHub Actions はどちらも、コードを自動的にビルド、テスト、リリース、リリース、デプロイするワークフローを作成します。一般に、ほとんどの企業にとって、CI プラットフォームを自社で開発する必要はなく、ツール間に絶対的な違いはありません.ここでは、両者の関係、類似点、および相違点について客観的な説明を行います.

2.3.1 Github アクションの利点

使いやすさ: Github Actions は非常に初心者に優しいです。開始するために必要なのは、YAML ファイルだけです。スタートアップ/小規模企業の場合、開発者はおそらく YAML についてすでにある程度知っているため、CI/CD プラットフォームとして Github Actions を選択するのは理にかなっています。

セットアップとメンテナンス: Jenkins では、カスタムサーバーで実行します。これは、Jenkins サーバーを継続的に維持する必要があることを意味します。ただし、Github Actions は、CI/CD アクションの実行に使用できる無料のランナーを提供します。これらのランナーは Github によって所有および管理されていますが、セルフホストランナーを追加することもできます。

2.3.2 Github アクションのデメリット

ロックダウン: Github アクションを使用すると、多かれ少なかれソース管理システムとして Github に結び付けられます。Jenkins を使用すると、Github、Gitlab、BitBucket などの任意のリポジトリにコードを保存できます。

成熟度: Jenkins は既に存在し、Github Actions よりも成熟しています。Github Actions は比較的新しいため、コミュニティのサポートはあまりありません。

2.3.3 ジェンキンスの利点

Jenkins を使用する利点の 1 つは、「フリーミアム」である Github Actions の対応物とは異なり、オープンソースで無料であることです。

プラグインを使用して、以前のビルドのファイルがキャッシュされ、必要に応じて新しいビルドで再実装されるキャッシングをサポートできます。

2.3.4 ジェンキンスの短所

Jenkins にはユーザーが利用できるプラグインがたくさんありますが、残念ながら、開発者によって定期的にメンテナンスされていないプラグインもあります。そのため、プラグインを使用する前に、プラグインが正しくサポートされているかどうかを確認する必要があります。

プラグインに大きく依存しており、プラグインの基本機能を見つけるのが難しい場合があります。

Jenkins インフラストラクチャを自分で維持および管理する必要があります。

リモート(クラウド)サーバーで Jenkins を管理するコストは、サーバーの負荷が不確実であるため、予測できない場合があります。これらの負荷には、コード量、アーティファクト量、コミット数などが含まれます。

2.3.5 類似点

Jenkins は宣言型 Pepelines を使用して、GitHub Actions ワークフローファイルに似たワークフローを作成します。

Jenkins はステージを使用して一連のステップを実行しますが、GitHub Actions はジョブを使用して 1 つ以上のステップまたは単一のコマンドをグループ化します。

Jenkins と GitHub Actions は、コンテナーベースのビルドをサポートしています。

ステップまたはタスクを再利用して、コミュニティと共有できます。

2.3.6 主な相違点

Jenkins には、パイプラインを作成するための構文として、宣言型パイプラインとスクリプトパイプラインの 2 種類があります。GitHub Actions は、YAML を使用してワークフローと構成ファイルを作成します。

Jenkins の展開は通常、自己ホスト型であり、ユーザーは自分のデータセンターでサーバーを維持します。GitHub Actions は、ジョブの実行に使用できる独自のランナーをホストすることでハイブリッドクラウドアプローチを提供し、セルフホストランナーもサポートします。

Github Actions vs Jenkins:次の表に、さらなる比較を示します。

GitOps は、ソースバージョン管理プラットフォーム Git を使用してインフラストラクチャと構成を管理する方法です。

非同期統合とは、ビルドが同時に実行され、ワークフローが高速化されることを意味します。Jenkinsに関しては、同期ビルドが主なものです。

アドホックワークフロー: Github アクションで発生するビルドの git イベントトリガーを監視します。一方、Jenkins は、bash スクリプトの実行、maven buildsm powershell など、多くのジョブを実行できます。コードベースにリンクせずにジョブを定期的に順番に実行する必要がある場合、Jenkins はそれを実行できます。

2.4 まとめ

Jenkins の成熟度と Unity のコンパイルの複雑さに基づいて、最終的に Jenkins を CI/CD ツールとして選択しました。

3 Unit Test CI（単体テスト継続的統合）

現在の効果は次のとおりです。Github がプルリクエストを発生させると、Jenkins が自動的にトリガーされて単体テストが実行され、実行結果が Github プルリクエストページにフィードバックされます。

以下は、主にGitHub プルリクエストを利用した場合の Jenkins 自動構築の設定手順を詳しく説明したもので、Jenkins 環境の構築と設定については、ここでは詳しく説明しません。

3.1 Github がトークンを生成する

GitHub のプロファイル画像をクリックし、[設定] > [開発者設定] > [個人用アクセストークン] を選択し、[新しいトークンを生成] ボタンをクリックして新しいトークン生成ページに入り、図に示されているオプションにチェックを入れ、[トークンを生成] ボタンをクリックしてトークンを生成します。生成されたトークンをコピーして保存します。

3.2 Jenkins で GitHub プルリクエストビルダープラグインをインストール/設定する

1. Jenkins > System Management > Plug-in Management > Optional Plug-ins で GitHub Pull Request Builder を検索し、直接インストールすることを選択します

2. Jenkins で資格情報を追加し、種類でシークレットテキストを選択し、シークレットで GitHub トークンを入力します。これは、後で GitHub プルリクエストビルダーを構成するときに使用されます。

3. 次に、GitHub のユーザー名とパスワードを使用して、後でタスクを構成するときに使用する別の資格情報を作成します。もちろん、すでに追加している場合は、再度構成する必要はありません。

4. 次に、Jenkins > System Management > System Settings > GitHub Pull Request Builder で次のように構成します。

GitHub サーバー API URL: デフォルトでは https://api.github.com、エンタープライズバージョンの場合は https://domain name/api/v3/ を入力します。

資格情報: GitHub によって生成されたトークンで以前に作成された資格情報を選択します。

上記内容を入力後、下のConnect to APIボタンでGitHubへの接続が正常かどうかを確認し、Check repo permissionsボタンで権限を確認できます。

3.3 Jenkins 設定タスク

3.3.1 新しいタスクを作成する

1. 新しいフリースタイルタスクを作成し、タスクを構成する

2. プロジェクトの GitHub URL を GitHub プロジェクト (ブラウザーに入力できるプロジェクト) に追加します。

3.3.2 ソースコード管理

構成ソースコード管理で GitHub のコードのアドレスを追加し、資格情報で GitHub アカウントとパスワードを使用して上記で作成した資格情報を選択します。

参照スペック：
- PR のみをビルドする場合は、refspec を +refs/pull/${ghprbPullId}/*:refs/remotes/origin/pr/${ghprbPullId}/* に設定します。
- PR とブランチを作成する場合は、refspec を +refs/heads/*:refs/remotes/origin/* +refs/pull/${ghprbPullId}/*:refs/remotes/origin/pr/${ghprbPullId } に設定します。 /*

指定されたブランチ: ${sha1} を入力します。提出された pr を使用する場合は、ここに ${ghprbActualCommit} を入力します。

3.3.3 ビルドトリガー

ビルドトリガーに管理者のリストを追加し、[ビルドトリガーに github フックを使用する] をオンにして、後ろにある [詳細設定] ボタンをクリックし、このタスクのプルリクエストを許可する GitHub ユーザーアカウントをホワイトリストに追加します。

3.3.4ビルド手順

1. ビルドここでは、プロジェクトの状況に応じて適切なビルドツールを選択します.私のプロジェクトは Gradle を使用してビルドされているので、[Invoke Gradle script] を選択します。

2. ビルドステップ Set build status to “pending on GitHub commit” を追加すると、ビルド中の GitHub プロジェクトの Pull requests に保留ステータスが表示されます。

3.4 Github の新しい Webhook

1. GitHub に対応するプロジェクトリモートウェアハウスで、Settings > Webhooks で新しい Webhook を作成し、下図のように Jenkins アドレスを入力します。

2. [個々のイベントを選択する] を選択し、[プルリクエスト] オプションをオンにします。

3. GitHub が Jenkins に正しく接続できる場合、Recent Deliveries の下にエラー報告のないレコードが表示されます。

4. この時点で、構成は完了です。次に、プルリクエストテストをプロジェクトの特定のブランチに送信します。PR が送信された後、保留中のチェックステータスが GitHub に表示されます。

5. Jenkins でビルドが正常にトリガーされました

6. ビルドが成功すると、GitHub のステータスがチェック成功に変わります。

3.5 その後の改善

Github の単一テスト結果の視覚化

Github 単独テスト結果が不合格または異常な場合、PR は許可されません

Github は、Jenkins 固有のビルドタスクへのジャンプをサポートしています

3.6 改善

Github は、Jenkins 固有のビルドタスクへのジャンプをサポートしています。

4 ありがとう

【CI/CDとは？この記事では、CI 継続的インテグレーションと CD 継続的デリバリー/デプロイ - Red Hat を理解することができます]

【ファウンパブ】

【GitHubプルリクエスト時のJenkins自動ビルドチュートリアル】

単体テスト CI/CD

序文

1CI/CD

1.1 CIとは

1.2 CDとは

1.3 CI/CD プロセス

2 CI プラットフォームの選択

2.1 GitHub アクション

2.2 ジェンキンス