ファイルからコマンドラインでPDF形式のドキュメントを生成するところまで出来ました。CIを使って自動化してみようと思います。大まかな流れは次のようになります。アカウントが無い場合はユーザー登録しましょう。Project」ボタンを押して新規プロジェクトを作成します。GitHubに既にプロジェクトがある場合はそちらからそっくりインポートする事も可能です。言う名前のファイルを作成します。Itemsの下に表示されます。ファイルの内容はとりあえずこんな感じにしておきます。部分で動作確認のためにJavaとRubyのバージョンを出力しています。.gitlab-ci.ymlファイルの仕様は下のページに載っています。GitLabにプッシュしてCIが動作することを確認するこの状態でGitLabにプッシュして見ます。Pipelinesというメニューをクリックすると自動的にPipelineが作成されている事が分かります。Jobsというサブメニューを開いて実行されたJobをクリックして詳細を表示すると、黒い画面でコンソール出力の結果を確認する事が出来ます。JavaとRubyのインストールが正常に行われて、最後にバージョン情報が表示されていれば成功です。リポジトリへのPushを検知してGitLab側で自動的にDockerコンテナを起動して指定のコマンドを実行してくれているわけですね。CIなど他のサービスを使わずに、しかも無料でこれが出来るというのがGitLabの良い所だと思います。Runner」というものを自前のサーバーにインストールしておけば、Dockerコンテナをそのサーバー上で起動させる様にする事も可能なようです。(むしろ元々は自前で用意するのが基本だったようです。Servicesを使います。コマンドを使ってみます。CIのジョブでdplコマンドを実行するための設定は次のようになります。コマンドをインストールしています。/^release-.*$/の部分は、「release-」で始まるタグ付きでプッシュされた時だけこのジョブが起動されるようにするための設定です。この2行を削除するとプッシュするたびに毎回起動されます。上の設定ファイルではデプロイ先のURLやデプロイ用の認証情報などを一切指定していません。variables」として登録しておきます。dplコマンドはAZURE_WA_SITEAZURE_WA_USERNAMEAZURE_WA_PASSWORDの3つの設定を自動的に読み込んで処理してくれます。APIが自動デプロイされます。下はデプロイ成功時のジョブのログを表示したところです。APIのPDFドキュメントを自動生成します。設定ファイルにpdfというジョブを追加しました。pdfとなっているので、「deployというステージが終わってからpdfというステージを実行する」という意味になります。ひとつのステージには複数のジョブを含める事が出来ますが、その場合はステージ内の各ジョブが並列実行されます。今回の設定ではそれぞれのステージに同名のジョブを一つずつ含んでいるだけという形になっています。それぞれのジョブは別個のDockerコンテナとして起動されるので、pdfジョブの方でも再度Rubyのインストールが必要になります。こちらのジョブではJavaのインストールも必要なのでdeployジョブよりも少し時間がかかります。フォルダにPDFファイルが作成されます。値を読み込んでスクリプトに渡しています。しておけばAzure側のデプロイ先が変わっても柔軟に対応出来るので便利ですね。生成されたPDFドキュメントをダウンロードする最新の成果物へは下の形式のURLでアクセス可能になっています。ジョブを追加してAWSやAzureなどのストレージにアップロードするような処理を追加することになると思います。あと、この設定のままだとジョブが起動される度に素のUbuntuに対してJavaやRubyのインストールから行っているので、終了するまでにかなり(数分程度)時間がかかってしまいます。出来ればJava/Rubyが既に入った状態のイメージを探してくるか自分で作成するかして、それをベースイメージに指定した方が良いと思います。今回作成したサンプルプロジェクトの全ソースコードは下記で参照可能になっています。