TOC

Ubuntu 16.04でBuildbotとの継続的な統合を設定する方法

前書き

Buildbotは、ソフトウェアのビルド、テスト、およびリリースのプロセスを自動化するためのPythonベースの継続的統合システムです。 前のチュートリアルでは、https：//www.digitalocean.com/community/tutorials/how-to-install-buildbot-on-ubuntu-16-04 [installed Buildbot]、https：//www.digitalocean.com/ community / tutorials / how-to-create-systemd-unit-files-for-buildbot [created systemd Unit files]は、サーバーのinitシステムがプロセスを管理できるようにし、https：//www.digitalocean.com/community/tutorials SSLで保護されたブラウザーリクエストをBuildbotのWebインターフェースに送信するために、/ how-to-configure-buildbot-with-ssl-using-an-nginx-reverse-proxy [リバースプロキシとしてNginxを構成]

このガイドでは、リポジトリへの新しい変更を自動的にテストするための継続的統合システムをセットアップする方法を示します。 簡単なNode.jsアプリケーションを使用して、テストプロセスと必要な構成を示します。 テスト環境をBuildbotホストから分離するには、Docbotイメージを作成してBuildbotワーカーとして実行します。 次に、Buildbotマスターを設定して、GitHubリポジトリの変更を監視し、新しい変更が検出されるたびに自動的にテストします。

前提条件

このチュートリアルを実行するには、次のものが必要です。

  • 少なくとも1 GBのRAMを搭載した1つのUbuntu 16.04サーバー。https：//www.digitalocean.com/community/tutorials/initial-server-setupに従って非ルートの「+ sudo +」ユーザーとファイアウォールを使用して設定-with-ubuntu-16-04 [Ubuntu 16.04初期サーバーセットアップガイド]

さらに、サーバーで次のチュートリアルを完了する必要があります。

これらの要件を完了したら、開始する準備が整いました。

GitHubのサンプルリポジトリをフォークする

Buildbotの設定を始める前に、このガイドで使用するサンプルリポジトリを見てみましょう。

Webブラウザーで、デモンストレーションに使用するhttps://github.com/do-community/hello_hapi[GitHubのhello hapiアプリケーション]にアクセスします。 このアプリケーションは、Node.js Webフレームワークであるhttps://hapijs.com/[hapi]で記述された、いくつかの単体テストと統合テストを備えたシンプルな「hello world」プログラムです。

この例は、さまざまな継続的統合システムのデモンストレーションに使用されるため、他のシステムのパイプラインを定義するために使用されるファイルに気付く場合があります。 Buildbotの場合、リポジトリ内ではなくサーバー上でビルド手順を定義します。

後で、リポジトリ内でBuildbotのWebhookを設定して、変更が自動的に新しいテストをトリガーするようにします。 今のところ、リポジトリの独自のフォークを作成する必要があります。

画面の右上隅にある*フォーク*ボタンをクリックします。

image：https：//assets.digitalocean.com/articles/buildbot_usage_1604/fork_repository.png [GitHub fork repository button]

GitHub組織のメンバーである場合、リポジトリの分岐先を尋ねられる場合があります。

image：https：//assets.digitalocean.com/articles/buildbot_usage_1604/where_to_fork.png [GitHubでレポをフォークする場所]

アカウントまたは組織を選択すると、リポジトリのコピーがアカウントに追加されます。

image：https：//assets.digitalocean.com/articles/buildbot_usage_1604/your_fork.png [GitHub your fork]

Buildbot構成内でフォークのURLを使用します。 リポジトリURLができたので、Buildbotの構成を開始できます。

Buildbot用のDockerのセットアップ

まず、Buildbotがそれを使用してビルドを実行できるようにDockerをセットアップします。 まず、DockerとBuildbot間のアクセスを構成する必要があります。 その後、コンテナに使用するDockerイメージを作成する必要があります。

BuildbotのDockerへのアクセスを構成する

BuildbotとDockerがいくつかの異なるレベルで通信できるようにする必要があります。

まず、BuildbotプロセスがDockerデーモンにアクセスできることを確認する必要があります。 これを行うには、* buildbot ユーザーを docker *グループに追加します。

sudo usermod -aG docker buildbot

この新しいグループは、Buildbotマスターが次回再起動されるときにBuildbotで使用可能になりますが、これは後で行います。

また、BuildbotがDockerとの通信方法を認識していることを確認する必要があります。 BuildbotはPythonで作成されているため、Dockerコマンドを直接発行する代わりにhttps://docker-py.readthedocs.io/en/stable/ [+ docker-py + Pythonパッケージ]を利用します。

次のように入力して、 `+ docker-py +`をインストールできます。

sudo -H pip install docker-py

最後に、コンテナからホストシステムおよび外部へのネットワークアクセスを開放する必要があります。 これを行うには、ファイアウォールの `+ docker0 +`インターフェースの例外を許可します。

次を入力して、 `+ docker0 +`インターフェースからのトラフィックへのアクセスを許可します。

sudo ufw allow in on docker0

BuildbotとDockerは互いに効果的に通信できるようになりました。

Buildbotワーカーとして使用するDockerイメージを作成する

次に、テストを実行するBuildbotワーカーとして使用するDockerコンテナーを作成します。 Buildbotは、Dockerコンテナーを動的に起動してワーカーとして使用できますが、最初にいくつかのBuildbotワーカーコンポーネントを含めてコンテナーを構築する必要があります。

幸いなことに、Buildbotプロジェクトは、すでにすべてのBuildbot固有の要件が構成されている基本的なhttps://hub.docker.com/r/buildbot/buildbot-worker/[Buildbot worker image]を提供します。 このイメージをベースとして使用し、プロジェクトに必要な追加の依存関係をインストールするだけです。

この場合、https：//github.com/do-community/hello_hapi [使用するサンプルアプリケーション]はNode.jsアプリケーションであるため、イメージでNode.jsが使用可能であることを確認する必要があります。

イメージを定義するには、ホームディレクトリに `+ Dockerfile +`というファイルを作成して開きます。

nano ~/Dockerfile

このファイルでは、 `+ FROM buildbot / buildbot-worker：master `を使用して、Buildbotワーカーイメージからイメージを作成します。 その後、 ` root `ユーザーに切り替えてNode.jsをインストールしてから、 ` buildbot +`ユーザーに戻って実際のコマンドを実行できます。

〜/ Dockerfile

FROM buildbot/buildbot-worker:master

USER root
RUN curl -sL https://deb.nodesource.com/setup_8.x | bash -
RUN apt-get install -y nodejs
USER buildbot

完了したら、ファイルを保存して閉じます。

`+ Dockerfile`を取得したら、それからイメージを構築できます。 イメージ `+ npm-worker +`を呼び出して、インストールした追加の依存関係を明示します。

docker build -t npm-worker - < ~/Dockerfile

Dockerは、 `+ Dockerfile `で説明したコマンドに基づいてイメージの構築を開始します。 基本イメージとその依存レイヤーをプルダウンし、Node.jsをインストールして、結果の環境を ` npm-worker +`というイメージに保存します。

Buildbotマスターを構成する

Dockerイメージができたので、それを使用するようにBuildbotマスターを構成できます。

完全に新しいビルドプロセスを定義しているため、マスター構成へのカスタマイズはこれまで最小限であったため、構成をゼロから開始します。 現在の情報が失われないように、元のファイルをバックアップファイルに移動します。

sudo mv /home/buildbot/master/master.cfg /home/buildbot/master/master.cfg.bak

バックアップファイルの構成を表示して、新しい構成で使用するいくつかの重要な値をコピーできるようにします。

sudo cat /home/buildbot/master/master.cfg.bak

新しい構成に移行する重要な部分は、ユーザーの資格情報とアクセス許可です。 出力で `+ c ['www'] ['authz'] `および ` c ['www'] ['auth'] +`で始まる構成セクションを探します。

Output. . .
c['www']['authz'] = util.Authz(
       allowRules = [
               util.AnyEndpointMatcher(role="admins")
       ],
       roleMatchers = [
               util.RolesFromUsername(roles=['admins'], usernames=[''])
       ]
)
c['www']['auth'] = util.UserPasswordAuth({'': ''})
. . .

これらの行をコピーして保存し、後で参照できるようにします。 これらの詳細を新しいBuildbotマスター構成に追加して、ユーザーと認証の設定を保持します。

ここで、Buildbotインスタンスの動作を再定義できる新しい `+ master.cfg +`ファイルを作成します。

sudo nano /home/buildbot/master/master.cfg

このファイルで新しいBuildbotマスター構成を定義します。

基本的なプロジェクト構成のセットアップ

Buildbot構成ファイルは実際にはPythonモジュールであり、多少の複雑さを犠牲にして優れた柔軟性を提供します。

基本的な設定から始めます。 ファイルに次の行を貼り付けます。

/home/buildbot/master/master.cfg

# -*- python -*-
# ex: set filetype=python:
from buildbot.plugins import *


c = BuildmasterConfig = {}

# Basic config
c['buildbotNetUsageData'] = None
c['title'] = "Hello Hapi"
c['titleURL'] = "https://github.com//hello_hapi"
c['buildbotURL'] = "https:///"
c['protocols'] = {'pb': {'port': 9989}}

ファイルの上部には、多くのテキストエディターが解釈して構文の強調表示を正しく適用できるコメントがいくつか含まれています。 その後、 `+ buildbot.plugins +`パッケージからすべてをインポートして、設定を構築するためのツールを利用できるようにします。

Buildbotの設定はすべて `+ BuildmasterConfig `という名前の辞書で定義されているため、この変数を空の辞書に設定して開始します。 ファイル全体で必要な入力の量を減らすために、この同じ辞書に設定された「 c +」という名前の略記変数を作成します。

次の構成で注意すべきいくつかの事項：

  • + buildbot GetImageData`は + None`に設定されます。 開発者に使用状況データを報告する場合は、これを文字列「+ "basic" +」に変更します。

  • `+ title `と ` titleURL +`はプロジェクトの名前とGitHubリポジトリを反映しています。 自分のフォークへのリンクを使用してください。

  • `+ buildbotURL `は、BuildbotマスターのSSLで保護されたドメイン名に設定されます。 ` https：// `で始まり、末尾のスラッシュ ` / +`で終わることを忘れないでください。

  • 最後の設定とは異なり、 `+ protocol`定義はlocalhostにバインドしません。 Dockerブリッジネットワーク `+ docker0 +`を介したDockerコンテナからの接続を許可する必要があります。

Dockerワーカーを構成する

次に、Dockerワーカーを定義する必要があります。 Buildbotは、必要に応じてDockerを使用してワーカーをプロビジョニングします。 そのためには、Dockerへの接続方法と使用するイメージを知る必要があります。

ファイルの下部に次を貼り付けます。

/home/buildbot/master/master.cfg

. . .

# Workers
c['workers'] = []
c['workers'].append(worker.DockerLatentWorker("npm-docker-worker", None,
                       docker_host='unix://var/run/docker.sock',
                       image='npm-worker',
                       masterFQDN=''))

`+ c ['workers'] = [] +`行は、設定を進める際に使用する基本的な規則を示しています。 構成辞書のキーを空のリストに設定します。 次に、リストに要素を追加して、実際の構成を実装します。 これにより、後で要素を追加する柔軟性が得られます。

ワーカーを定義するには、 + worker.DockerLatentWorker +`インスタンスを作成して `+ worker +`リストに追加します。 このワーカーに「+ npm-docker-worker +」という名前を付けて、後で構成で参照できるようにします。 次に、 `+ docker_host +`をDockerのソケットの場所に設定し、作成したDockerイメージの名前（この例では `+ npm-worker +）を指定します。 Buildbotマスターのドメイン名に「+ masterFQDN +」を設定して、サーバーの内部ホスト名の設定に関係なく、コンテナーがマスターに到達できるようにします。

スケジューラーを構成する

次に、スケジューラを定義します。 Buildbotは、スケジューラを使用して、変更ソースまたは変更フックから受け取る変更に基づいてビルドを実行するタイミングと方法を決定します（変更フックは後で構成します）。

ファイルの下部に次の構成を貼り付けます。

/home/buildbot/master/master.cfg

. . .

# Schedulers
c['schedulers'] = []
c['schedulers'].append(schedulers.SingleBranchScheduler(
               name="hello_hapi",
               change_filter=util.ChangeFilter(project='/hello_hapi', branch='master'),
               treeStableTimer=3,
               builderNames=["npm"]))

ここでは、空のリストに設定を追加するのと同じ方法を使用します。 この場合、 `+ schedulers.SingleBranchScheduler +`インスタンスを追加します。 これにより、リポジトリ上の単一のブランチを監視できるため、構成が簡素化されます。

スケジューラを適切に識別するために、スケジューラに「hello_hapi」という名前を付けます。 次に、変更フィルターを定義します。 異なるソースからの多くの異なる変更セットがスケジューラに渡される場合があります。 変更フィルターは、問題の変更をこの特定のスケジューラーで処理する必要があるかどうかを決定する一連の基準を定義します。 この例では、GitHub webhookによって報告されるプロジェクトの名前と、監視したいブランチに基づいてフィルタリングします。

次に、追加の変更を待機する時間を決定する「+ treeStableTimer +」を3秒に設定します。 これは、Buildbotが密接に関連する変更のために多くの小さなビルドをキューに入れないようにするのに役立ちます。 最後に、変更が基準に一致するときに使用するビルダーの名前を定義します（このビルダーを一時的に定義します）。

Node.jsプロジェクトのビルドファクトリを構成する

次に、Node.jsプロジェクトを処理するためのビルドファクトリを構成します。 ビルドファクトリは、プロジェクトをビルドするために実行する必要がある手順を定義する責任があります。このテストでは、プロジェクトをテストします。 これは、 `+ util.BuildFactory +`インスタンスを定義してから、実行する必要のある順次ステップを追加することにより行います。

ファイルの下部に次を貼り付けます。

/home/buildbot/master/master.cfg

. . .

# Build Factories
npm_f = util.BuildFactory()
npm_f.addStep(steps.GitHub(repourl='git://github.com//hello_hapi.git', mode='full', method='clobber'))
npm_f.addStep(steps.ShellCommand(command=["npm", "install"]))
npm_f.addStep(steps.ShellCommand(command=["npm", "test"]))

最初に、 `+ npm_f `というビルドファクトリを定義します。 追加する最初のステップは、 ` steps.GitHub`インスタンスです。 ここでは、ビルダーにプルダウンするリポジトリを設定します。 新しいコードを取得するたびにリポジトリを完全にクリーンアップするために、「+ mode」を「full」に、「+ methods」を「clobber」に設定します。

追加する2番目と3番目のステップは + steps.ShellCommand +`オブジェクトで、ビルド中にリポジトリ内で実行するシェルコマンドを定義します。 このケースでは、プロジェクトの依存関係を収集するために `+ npm install +`を実行する必要があります。 その後、テストスイートを実行するために `+ npm test`を実行する必要があります。 リスト内のコマンド（ `+ [" npm "、" install "] +）を定義することは、シェルがコマンド内の要素に不要な展開を適用しないようにするために、ほとんどの場合に推奨されます。

ビルダーを構成する

手順が追加されたビルドファクトリができたら、ビルダーをセットアップできます。 ビルダーは、既に定義した多くの要素を結び付けて、ビルドの実行方法を決定します。

ファイルの下部に次の構成を貼り付けます。

/home/buildbot/master/master.cfg

. . .

# Builders
c['builders'] = []
c['builders'].append(
       util.BuilderConfig(name="npm",
               workernames=["npm-docker-worker"],
               factory=npm_f))

`+ utilsBuilderConfig `オブジェクトを ` builders `リストに追加します。 ビルドファクトリは「 npm_f 」と呼ばれ、Dockerワーカーは「 npm-docker-worker 」と呼ばれ、定義したスケジューラーはタスクを「 npm +」というワーカーに渡すことを忘れないでください。 ビルダーはこれらの要素間の関係を定義するため、スケジューラーからの変更により、Dockerワーカーでビルドファクトリのステップが実行されます。

データベースとWebインターフェイスを構成する

最後に、データベースとWebインターフェイスの設定を構成できます。 これまでの多くの項目とは異なり、これらの2つの設定はリストではなく辞書として定義されています。 `+ db `辞書は、すでに ` / home / buildbot / master `ディレクトリにある ` state.sqlite `ファイルを指しているだけです。 ` www +`辞書には、かなりの量の追加設定が含まれています。

ファイルの下部に次を貼り付けます。 元のBuildbotマスター構成からコピーした認証情報を、以下の認証ブロックに置き換えます。

/home/buildbot/master/master.cfg

. . .

# Database
c['db'] = { 'db_url': "sqlite:///state.sqlite",}

# Web Interface
c['www'] = dict(port=8010, plugins=dict(waterfall_view={}, console_view={}))













# GitHub webhook receiver
c['www']['change_hook_dialects'] = {
       'github': {
               'secret': '',
               'strict': True,
       }
}

データベース設定を定義した後、リッスンするポートとWeb UIに含めるビューの一部を定義することから始まる「+ www +」辞書を作成します。 次に、以前のBuildbot構成ファイルから取得した認証要件を追加します。

最後に、 `+ www `辞書内に ` change_hook_dialects `という辞書を定義します。 これを使用して、GitHubからのwebhookメッセージをリッスンするGitHub変更フックを定義します。 GitHubが送信するメッセージの認証に使用する「 secret +」の安全なパスフレーズを選択します。

終了したら、ファイルを保存して閉じます。

Buildbotマスターを再起動して新しい構成を適用する

この時点で、Buildbotマスタープロセスを完全に再構成しました。 変更を実装するには、Buildbotマスタープロセスを再起動する必要があります。

それを行う前に、ファイルの構文エラーを確認することが重要です。 ゼロから構成を再構築したため、いくつかの間違いが発生した可能性があります。

次のように入力して、ファイルの構文を確認します。

sudo buildbot checkconfig /home/buildbot/master

コマンドは、見つかった問題を報告します。 エラーが見つからなかった場合、次のようなメッセージが表示されます。

OutputConfig file is good!

エラーが報告された場合は、エラーメッセージを注意深く読んで、何が問題なのかをよりよく理解してください。 構成ファイルを再度開いて、問題を修正してください。

エラーがなくなったら、次を入力してBuildbotマスターサービスを再起動します。

sudo systemctl restart buildbot-master

次のように入力して、操作が成功したかどうかを確認します。

sudo systemctl status buildbot-master
Output● buildbot-master.service - BuildBot master service
  Loaded: loaded (/etc/systemd/system/buildbot-master.service; enabled; vendor preset: enabled)
   since Tue 2017-06-27 19:24:07 UTC; 2s ago
Main PID: 8298 (buildbot)
   Tasks: 2
  Memory: 51.7M
     CPU: 1.782s
  CGroup: /system.slice/buildbot-master.service
          └─8298 /usr/bin/python /usr/local/bin/buildbot start --nodaemon

Jun 27 19:24:07 bb5 systemd[1]: Started BuildBot master service

サービスが正常に再起動できた場合、アクティブとしてマークされます。

サンプルリポジトリでGitHub Webhookを作成する

BuildbotがGitHub Webhook投稿を受け入れるようにWebエンドポイントで構成されたので、フォーク用のWebhookを構成できます。

Webブラウザで、サンプルプロジェクトリポジトリのフォークに移動します。

https://github.com//hello_hapi

[設定]タブをクリックして、プロジェクトの設定を表示します。 設定ページの左側のメニューで、[* Webhooks *]をクリックします（GitHubでは、このプロセス中にIDを確認するためにパスワードを再入力するよう求められる場合があります）。

image：https：//assets.digitalocean.com/articles/buildbot_usage_1604/webhooks_initial_page.png [GitHub webhooks initial page]

右側にある[* Webhookの追加*]ボタンをクリックして、新しいWebhookを追加します。

次のページには、Webhookを定義するフォームが含まれます。 [*ペイロードURL *]フィールドに、プロジェクトのGitHub変更フックエンドポイントのURLを追加します。 これは、「+ https：// 」プロトコルに続けてBuildbotマスターのドメイン名を指定し、その後に「 / change_hook / github +」を指定することで構築されます。

コンテンツタイプは「+ application / x-www-form-urlencoded +」に設定したままにします。 * Secret *フィールドに、Buildbotマスター構成ファイルで選択したシークレットパスフレーズを入力します。 「プッシュイベントのみ」トリガーを選択したまま、「アクティブ」チェックボックスをオンのままにすることができます。

image：https：//assets.digitalocean.com/articles/buildbot_usage_1604/webhooks_form.png [GitHub webhooks form]

完了したら、[Webhookを追加]ボタンをクリックします。

プロジェクトのwebhookインデックスに戻り、新しいwebhookが表示されます。 数回更新すると、ウェブフックの横に緑色のチェックマークアイコンが表示され、メッセージが正常に送信されたことを示します。

image：https：//assets.digitalocean.com/articles/buildbot_usage_1604/webhooks_success_icon.png [GitHub webhook success icon]

代わりに赤いXが表示される場合は、Webhookをもう一度クリックしてから、* Recent Deliveries *セクションまでスクロールします。 失敗した配信をクリックすると、問題の詳細を確認できます。

Webhookのテスト

これでWebhookが準備できたので、リポジトリに変更を加えたときにBuildbotがアラートを受け、Dockerでビルドをトリガーし、テストスイートを正常に実行できることを確認するためにテストできます。

GitHubフォークのメインページで、緑色の[クローンまたはダウンロード]ボタンの左側にある[新しいファイルを作成]ボタンをクリックします。

image：https：//assets.digitalocean.com/articles/buildbot_usage_1604/create_new_file_button.png [GitHub新規ファイル作成ボタン]

次の画面で、 `+ dummy_file +`を作成し、テキストを入力します。

image：https：//assets.digitalocean.com/articles/buildbot_usage_1604/create_dummy_file.png [GitHubダミーファイルの作成]

完了したら、ページの下部にある[新しいファイルをコミット]ボタンをクリックします。

次に、Buildbotウェブインターフェースにアクセスし、まだ認証されていない場合はログインします。

`+ dummy_file +`をリポジトリにコミットしてからの時間に応じて、次のような進行中のビルドが表示される場合があります。

image：https：//assets.digitalocean.com/articles/buildbot_usage_1604/in_progress_build.png [Buildbot in progress build]

ビルドが既に完了している場合、代わりに「最近のビルド」セクションにあります。

image：https：//assets.digitalocean.com/articles/buildbot_usage_1604/build_complete.png [Buildbot build complete]

定義したビルダーの名前「npm」は、ビルドのラベル付けに使用されます。 この例では、以前のマスター構成からのサンプルビルダーの古い実行も確認できます。

進行状況に関係なく、ビルダー名とビルド番号のリンクをクリックして、ビルドの詳細ページにアクセスします。 このビューには、実行されたビルドに関する情報が含まれています。 ビルドファクトリに追加した各ステップは、独自のセクションに表示されます。

image：https：//assets.digitalocean.com/articles/buildbot_usage_1604/build_details_view.png [ビルドボットのビルド詳細ビュー]

ステップをクリックすると、コマンドからの出力が表示されます。 これは何かがうまくいかない場合のデバッグに役立ちます：

image：https：//assets.digitalocean.com/articles/buildbot_usage_1604/build_step_output.png [ビルドボットのビルドステップ出力]

上記の出力では、Buildbotがテストスイート内の3つのテストを正常に実行したことを確認できます。

ビルドが正常に完了しなかった場合、確認したい他の領域は、ビルドの詳細ページの他のタブと `+ / home / buildbot / master / twistd.log +`ファイルです。

Buildbotサービスの調整

完了する前に、Buildbotサービスにいくつかの調整を行う必要があります。

現在、使用していないワーカーに対して定義された `+ buildbot-worker +`サービスがあります（必要に応じてDockerワーカーが自動的に開始されます）。 古いワーカーを停止して無効にする必要があります。

実行中のサービスを停止し、起動時に開始しないようにするには、次を入力します。

sudo systemctl stop buildbot-worker
sudo systemctl disable buildbot-worker
OutputRemoved symlink /etc/systemd/system/buildbot-master.service.wants/buildbot-worker.service.

上記の出力は、ワーカーが次回の起動時に起動されないことを示しています。 サービスが実行されていないことを確認するには、次を入力します。

sudo systemctl status buildbot-worker
Output● buildbot-worker.service - BuildBot worker service
  Loaded: loaded (/etc/systemd/system/buildbot-worker.service; disabled; vendor preset: enabled)


Jun 27 21:12:48 bb6 systemd[1]: Started BuildBot worker service.
Jun 27 21:55:51 bb6 systemd[1]: Stopping BuildBot worker service...
Jun 27 21:55:51 bb6 systemd[1]: Stopped BuildBot worker service.

最後にすべきことは、BuildbotマスターサービスとDockerデーモンの間にソフトな依存関係を確立することです。 BuildbotマスターサービスはDockerなしでは新しいワーカーをプロビジョニングできないため、この要件を定義する必要があります。

+ / etc / systemd / system`ディレクトリ内の + buildbot-master.service ie`ファイルを開いて、サービスファイルを調整します。

sudo nano /etc/systemd/system/buildbot-master.service

+ [Unit] +`セクションで、 `+ network.target`アイテムの後の + After`ディレクティブに `+ docker.service`を追加します。 さらに「+ docker.service 」という名前の「 Wants 」ディレクティブを追加します。 ` Wants `はソフト依存関係を確立し、 ` After +`ディレクティブは開始順序を確立します：

/etc/systemd/system/buildbot-master.service

[Unit]
Description=BuildBot master service
After=network.target


[Service]
User=buildbot
Group=buildbot
WorkingDirectory=/home/buildbot/master
ExecStart=/usr/local/bin/buildbot start --nodaemon

[Install]
WantedBy=multi-user.target

完了したら、ファイルを保存して閉じます。

systemdデーモンとサービスをリロードして、構成をすぐに適用します。

sudo systemctl daemon-reload
sudo systemctl restart buildbot-master

これで、Dockerが使用可能になった後にBuildbotマスタープロセスが開始されます。

結論

このチュートリアルでは、webhookを使用してGitHubリポジトリへの変更をリッスンするようにBuildbotを構成しました。 変更が受信されると、BuildbotはカスタムDockerイメージに基づいてコンテナーを起動し、新しいコミットをテストします。 Dockerイメージには、Buildbotワーカーインスタンスと、プロジェクトコードのテストに必要な依存関係が含まれています。 これにより、Buildbotは、リポジトリに変更が加えられるたびに、必要に応じてBuildbotワーカーを動的に起動できます。

Related