Hnoss

Hnoss

GitLabのドキュメントが、CC BY-SA 4.0.になったー!やったー!
カレンダー

文書タグ

フノス(訳者)(215) IT(191) 解説記事(147) マニュアル(82) GitLab CI(60) オープンソース(50) GitLab(40) Linux(38) メディア(34) コンテナ(29) ウェブ制作(27) DTM(19) HTML5(19) おすすめ オープンソース・ソフトウェア(18) Libre Music(18) 百科事典(14) プラグイン(14) 文化(12) ミキシング(11) ソフトウェア(11) セキュリティ(11) 録音(11) MIDI(10) 西アジア/中東(10) 料理(9) ジョージア(9) グルジア(9) 東ヨーロッパ(9) 業務効率化(8) 音楽編集(8) コマンド(8) シーケンス(8) 芸能(8) ハンドブック(7) マスタリング(7) 音楽(7) 経済(7) アプリ(6) Raspberry Pi(6) JACK(5) マイクロサービス(5) Google(5) ワークフロー(5) WordPress(5) GNU(4) 法律(4) 欧州(4) 音楽プレーヤー(4) Ubuntu(4) 北米(4) Windows(4) Android(4) 映像制作(4) ソーシャルメディア(3) DAW(3) Python(3) アニメ(3) ホームオートメーション(3) アニメーション(3) IoT(3) Ardour(3) 社会(3) Java(3) エジプト(2) ALSA(2) OS X(2) ERPシステム(2) 電子ブック(2) トヨタ(2) バト(2) Krita(2) 電子書籍(2) ウィッカ(2) GPL(2) ERP(2) オカルト(2) Twitter(2) ロスレス音源(2) BountySource(2) スマホ(2) 牛(2) 歴史(2) ニュース(2) GNOME3(2) iOS(2) PlayStation(2) 仮想通貨(2) 古代エジプト(2) マーケティング(2) 有角神(2) 出エジプト記(1) 観光案内(1) 絵文字(1) サンフランシスコ(1) パキスタン(1) リクルート(1) ハトホル(1) パン(1) 地方(1) Blender(1) 羊神(1) ギリシャ(1) 高速道路情報無線(1) ツイッター(1) Youtube(1) 中南米(1) モヘンジョ=ダロ(1) CC(1) 声明(1) 悪魔(1) ラジオ(1) アレクサンドロス大王(1) ローマ(1) ポッドキャスト(1) ゲーム(1) パシュパティ(1) 1Password(1) アピス(1) 宗教(1) テレビ(1) OpenToonz(1) 電子教材(1) 船乗りの柱(1) シリア(1) GPS(1) アフリカ(1) リグ・ヴェーダ(1) F-Droid(1) デザイン(1) ムネヴィス(1) ネオペイガニズム(1) コミュニティ放送(1) アンビソニック(1) 元ネタ(1) ケルヌンノス(1) ナイジェリア(1) 日記(1) 聖書(1) 任天堂 DS(1) 教育(1) bi-modal IT(1) 魔女宗(1) アクティブSETI(1) バイノーラル(1) Papagayo(1) 写真(1) 意味(1) コシディウス(1) インド(1) ユーコン(1) ヤーウェ(1) CD(1) タブレット(1) 学校(1) 日本(1) 羊(1) ベルゼブブ(1) デジタルサイネージ(1) VR(1) アップストリーム・パッケージング(1) 画像(1) 由来(1) グンデストルップの大釜(1) カナン(1) カナダ(1) サウンドフォント(1) 詩篇(1) チップチューン(1) バ・ネブ・デデト(1) コットン・マザー(1) クラウドキャスティング(1) VST(1) ポータブルソフトウェア(1) エリファス・レヴィ(1) マサチューセッツ(1) 考古学(1) 申命記(1) クヌム(1) 魔女裁判(1) オンデマンド(1) リーナス・トーバルズ(1) バフォメット(1) UNIX(1) 黙示録(1) スタジオジブリ(1) アモン(1) セイラム魔女裁判(1) ねじ巻きラジオ(1) 3D(1) 政治(1) イボ人(1) 国際(1) クリエイティブ・コモンズ(1) amazon(1) キリスト教(1) レビ記(1) Synfig(1) 独占(1) アマナイ(1) 広告(1) KXStudio(1) EU(1) イケンガ(1) 国際公文書館会議(1) マイナビ(1) 募金(1) ユダヤ教(1) ウルガタ聖書(1) 科学技術(1)
リファレンス

first-time visitors
user guide
謝辞

「みんなの翻訳」は情報通信研究機構言語翻訳グループ東京大学図書館情報学研究室による共同プロジェクトであり、三省堂国立情報学研究所連想情報学研究開発センターが開発に協力しています。三省堂には「グランドコンサイス英和辞典(36万項目収録)」の使用を許可していただきました。

連携研究グループはこちらをご覧ください。

「みんなの翻訳」を使っている翻訳グループについてはこちらをご覧ください。

バナー

logo

ポスター

poster

フライヤー

poster poster
Mozilla Firefox ブラウザ無料ダウンロード
本サイトはブラウザ「Mozilla Firefox」推奨です。
Firefox3で動作確認しています。

Valid XHTML 1.0 Transitional


GitLab DocumentationUser documentationProjectsGitLab Pages 説明書>ウェブサイトで必要な「.gitlab-ci.yml」設定

この記事は、Marcia Ramos が2017年2月22日に発表したものを、2018年2月16日に更新したものです。種類:ユーザーガイド・レベル:中級

 GitLab CIサーバーは、アプリの継続的インテグレーションにおける、あらゆる工程を実行します。ビルド、テスト、デプロイ、これらの作業をCIサーバーに担わせることができます。
 GitLab Pagesも「ウェブサイト」という、1種のアプリとして捉えることが可能です。ビルドしたウェブサイトは、専用のPagesサーバーにデプロイすることになります。

 さて、ようやく GitLab CI/CDを実装するには、ウェブサイトの rootディレクトリに「.gitlab-ci.yml」設定ファイルを作成する必要があります。

 このファイルには、GitLab ランナーに実行してもらうスクリプトを記述します。元々はあなたがコマンドラインから出していた指示を、このファイルに記録してしまうのです。
 ここでいうランナーは、皆さんがお使いのターミナルのような役割を果たします。GitLab CI/CD は、ファイルの中身を読み取って、ランナーにコマンドを出す部分です。
 CI/CDもランナーも、どちらもGitLabに備え付けてあるものなので、動作させるために利用者が何かの設定する必要はありません。

 GitLab ランナー と GitLab CIの詳しい説明につきましては、このページでは触れません。その代わり、「.gitlab-ci.yml」ファイルを設定する上で、押さえてもらいたいポイントを以下にまとめました。
「.gitlab-ci.yml」設定ファイルは、Yamlファイルである。よって、yamlシンタックスで記述する。
CI シンタックスが正しいかどうかは、GitLab CI Lint ツールを使って判定する。

 実施例

 それでは、最も代表的な静的サイトジェネレータである、Jekyllを使ったサイトの設定ファイルの作り方を紹介します。
 まずローカル環境でJekyllサイトをビルドするには、ターミナル開いて「jekyll build」というコマンドを入れるのが普通でしょう。もちろん、ビルドに入る前には、皆さんのコンピューターには Jekyllをインストールしておかなくてはなりません。
 Jekyllのコード言語はgemなので、「gem install jekyll」というコマンドを使います。ここまでは良いですか?

 GitLab CI + GitLab Runner にも、まるで同じ指示を出します。「.gitlab-ci.yml」にビルドなどに必要とされるスクリプトを、全部記述してください。GitLabランナーはその通りに動作するでしょう。

 もう一度、Jekyllをビルドする上で核となるコマンドを確認します。
 これから肉付けしていく要素に気を取られてしまいそうになりますが、これらは絶対外せません。

======================
$ gem install jekyll

$ jekyll build
======================

 Script

 上のコマンドをYaml書式に変換すると、次の通りになります。

======================
script:
 - gem install jekyll
 
- jekyll build
======================

 Job

 たった上の設定だけでも、ランナーは動くと言えば動くんです。
 でも、実際は、それぞれのscriptたちに、jobという単位を設けて、タスクごとに分類してないと後が大変です。

======================
job:
 script:
  - gem install jekyll
 
 - jekyll build
======================

 さらに、GitLab Pagesをビルドする時には、job名を「pages」としなくてはなりません。「pages」という記号が、ランナーにとっては、GitLab Pages(ウェブサイト)をデプロイする合図になっています。

======================
pages:
 script:
  - gem install jekyll
  
- jekyll build
======================

 public ディレクトリ

 job名を「pages」にしただけでは、ウェブサイトは出来上がりません。なぜなら、ウェブサイトをビルドするディレクトリを指定しないからです。
 GitLab Pagesで、そのディレクトリに指定できるのは、「public」ディレクトリのみです。
 "どこにビルドするか"を指定するには、jekyll buildの後に、(-d)でディレクトリを指定します。(つまり「website: jekyll build -d public」)

======================
pages:
 script:
  - gem install jekyll
  
- jekyll build -d public
======================

 ビルド物の置き場指定

 さっき、ランナーにビルドをする場所を教えましたが、ビルドしたあとの物(artifacts)をどこにやるかを指定していません。
 もちろん、publicディレクトリと指定しないと、サイトが出来上がりません。job名がpagesという時点で、置く場所は殆ど決まっているのにねえ。

======================
pages:
 script:
  - gem install jekyll
 
 - jekyll build -d public
  
artifacts:
   paths:
    - public
======================

 以上のスクリプトさえあれば、JekyllサイトをGitLab Pagesでビルドするには十分です。

 しかし、Jekyll 3.4.0以降からは、開発プロジェクトの方針で、依存関係のインストールに Bundlerを使うようになりました。Jekyllのインストールとデフォルトテーマの導入には、Bundlerが必要です。
 上のスクリプトを次の通りに変換します。scriptの部分にだけ変更があって、「public」をサイトのディレクトリに指定することに変わりはありません。

======================
pages:
 script:
  - bundle install
  - bundle exec jekyll build -d public
  artifacts:
   paths:
    - public
======================

  Jekyll 3.4.0で作成するサイトは、この設定でビルド可能です。
 以上!最低限、この設定だけはしなくてはならないものを紹介しました。
 力作の「.gitlab-ci.yml」が、何故か動かないときには、この最も基本的な設定に抜け・漏れがないかを確認してください。

 ちなみに、Artifactsはサーバーがウェブサイトを立ち上げるために使う簡易キットみたいなものです。GitLab Pagesにウェブサイトがデプロイされると、自動的に削除されます。保存期間を指定しておくと、その期間だけはArtifactsが消去されないように変更できます。

 Image

 設定ファイルには、サイトジェネレータと依存関係にあるソフトを入れるコマンドを記述しなくてはならりません。
 「確かその筈…、あらら?Rubyのインストールはどうしたの?そのスクリプトどうやって書くの?」
 覚えてしまえば簡単です。最初に「image: 」パラメータを使います。
 ライブラリを導入するときは、scriptではなく、imageに記述したほうが、ビルドが安定します。
 これはランナーに 、Dockerイメージを用意させて、その中でscriptを実行させる方法です。

======================
image: ruby:2.3

pages:
 script:
  - bundle install
  
- bundle exec jekyll build -d public
  artifacts:
   paths
:
    - public
======================

 この場合に、ランナーが引き出してくるDockerイメージは、Ruby 2.3が、ファイルシステムの一部として導入されているコンテナです。

「じゃあ、さっきの設定は image: を指示していなかったのに、どうしてうまくいったの?」
と疑問に思う方もいらっしゃるでしょう。
 実は、GitLabではビルドに使用するコマンド(gem, bundleなど)に応じて、デフォルトで使用するイメージが定められています。
 たとえば、Ruby系のコマンドなら、Ruby 2.1 が入ったイメージが、自動適用されます。

 ただし、NodeJS がビルドの際に必要な静的サイトジェネレータについては、NodeJSのバージョンを必ず image: で指示しなくてはなりません。ファイルシステムの中に、ジェネレータに当てはまるライブラリが入っていないと、ビルドが失敗します。
 例:Hexoサイトのビルドには、image: node:4.2.2 が必要。

注:どのDockerイメージを使えばよいか不明なら、「最低限これだけは必要そう」というイメージを選びましょう。このような時に、Dockerイメージについて、ある程度の知識があると便利です。イメージについての説明が書かれているサイトを見ましょう。こちらの記事も参考になります。


 コマンドをscriptにすることと、ライブラリをimageで揃えるところまでが、「.gitlab-ci.yml」の基本です。
 次はもう少し込み入った設定まで行ってみましょう。


 ブランチわけ

 GitLabをバージョン管理ソフトとして使っている方なら、プロジェクトにブランチをつけることが当たり前のようになっていることでしょう。大抵のプロジェクトなら、同じプロジェクトでもブランチごとに、少し違った開発をすることが多いものです。

 しかし、ウェブサイトの場合は、デフォルト・ブランチ(たいてい master)だけにプッシュした方が良いでしょう。
 pagesに書かれたスクリプトが、誤って動作するリスクを減らすためには、「only: -master」と設定して、ウェブサイトプロジェクトのmasterブランチにプッシュがあったときにだけ、ランナーを動かすように設定してください。

======================
image: ruby:2.3

pages:
 script:
  - bundle install
  
- bundle exec jekyll build -d public
  artifacts:
   paths:
    - public
   only:
    - master
======================

 Stages

 今までの設定は、すべて「build」ステージの工程であることを念頭に置いておくと、設定のバリエーションを広げられます。ウェブアプリの開発なら、たくさんのテストを通してから、デプロイすることになりますが、それらの工程を大まかにタグ付けすることで、ランナーにより多くの作業を任せられます。
 「stages:」パラメータでは、デフォルトで、build, test, deployの3つのタグが用意されています。現在のjob(ここではpages:)が、今どの工程に属しているかを、CIに読み取らせる記号です。

======================
image: ruby:2.3

pages:
 stage: deploy
 script:
  - bundle install
 
 - bundle exec jekyll build -d public
  artifacts:
   paths:
    - public
   only:
    - master
======================

 「ウェブサイトもアプリの一種なんでしょ。だったら、test用のjobを設けることもできる?」と考えられたなら、あなたは鋭い。

 できますよ。「stages: -test」と書かれているjobさえあれば、サイトをデプロイする前に、何らかのバグ検閲テストをかけられます。

 masterブランチにプッシュする前に、scriptにテストのコマンドを入れたい場合、
masterブランチ以外(exept: -master)にプッシュがされたら、テスト用のjobが作用するような、
タスク(job)をもう1つ追加すれば良いのです。

======================
image: ruby:2.3

pages:
 stage: deploy
 script:
  - bundle install
 
 - bundle exec jekyll build -d public
  artifacts:
   paths:
    - public
   only:
    - master


pages:
 stage: test
 script:
  - bundle install
 
 - bundle exec jekyll build -d test
  artifacts:
   paths:
    - test
   except:
    - master
======================

 新たに追加された「test」jobは、Jekyllサイトを testディレクトリにビルドします。masterブランチでないところにプッシュすれば、必ず作用するように設定しました。

 この先、test jobに新たな項目を追加すれば、stage buildとは違ったjobにしていけるようになったというところで、前のコンフィグと大きく差が付いたのではないでしょうか。
 もし、デプロイ前にさらなる試験が必要そうなら、他のテストも追加するとよいでしょう。アプリのテストは、1つのテストが終了しなければ、他のテストができないわけではありません。このjobに記述したテストは、すべて同時に実行することができます。
 「stage」によるjobの分類のさわりは、これでよいでしょう。他のCIツールでも同じような機能があるはずです。とてもよいテストツールを知っているのなら、このようにstage分けをしたほうが効果的ですが、GitLab Pagesでサイトを作る分には、このあたりの設定はほどほどでよいのではないでしょうか。

 Before Script

 jobが複数個になりました。すると、それぞれのjobに「bundle install」というコマンドがあることになります。

 それぞれのjobは同時に作動させることが可能です。そのときにあちこちのjobで、同じコマンドを一斉に使い始める現象が起こってしまうことがあります。こうなると、ランナーにもそれなりに負荷がかかります。
 これを避けるために、「複数のjobで使用するコマンドを、1つのjobとして扱ってしまう」方が、機械にとって都合が良いわけです。

 そこで、両方のjobにある、「bundle install」というコマンドに、「before_script:」というjobを設けて、ランナーに2度手間を負わせない設定にします。

======================
image: ruby:2.3

before_script:
 - bundle install

pages:
 stage
: deploy
 script:
  - bundle exec jekyll build -d public
  artifacts:
   paths
:
    - public
   only:
    - master


pages:
 stage
: test
 script:
 
 - bundle exec jekyll build -d test
  artifacts
:
   paths
:
    - test
   except:
    - master
======================

 キャッシュがけ

 ビルドの時間を短縮したかったら、プロジェクトと依存関係にあるバイナリなどに、キャッシュをかけるとよいでしょう。そこで使われるのが「chache」パラメータです。

 この例では、Jekyllの依存関係である「bundle install」にキャッシュを設けています。キャッシュを使うには、まずキャッシュを置くディレクトリをきちんと指定しなくてはなりません。ここでは「vendor/」ディレクトリとなっています。

======================
image: ruby:2.3

cache:
  paths:
   - vendor/

before_script:
 - bundle install

pages:
 stage
: deploy
 script:
  - bundle exec jekyll build -d public
  artifacts:
   paths:
    - public
   only:
    - master


pages:
 stage
: test
 script:
 
 - bundle exec jekyll build -d test
  artifacts:
   paths
:
    - test
   except:
    - master
======================

 まだ、Jekyllサイトを作るのは待ってください。ここで設定したのは、ランナーだけが使うキャッシュファイルなので、ビルドの時にだけ必要とされます。
 つまり、これは誤ってアプリの中に組み込まれてはならないものなのですが、Jekyllには、CI設定で提示されたファイルを、手当たり次第にアプリにしていく性質があります。

 「.gitlab-ci.yml」の設定が終わったら、次はJekyllの「_config.yml」を開いて次の設定をしてください。

======================
exclude:
 - vendor
======================

 さあ、プッシュしてみましょう。

 GitLab CIは、ウェブサイト(アプリ)をビルドするのが基本だとして、ブランチわけ、キャッシュがけ(ここではbundleにかけた。)、その他特殊なjobを追加するような、応用技をかけられます。
 masterブランチにプッシュがなされれば、すぐさまデプロイが始まります。

 GitLab Pagesに GitLab CIで さらに工夫を凝らす

 ざっと覚えてほしい項目は、以上の通りですが、GitLab CIには、まだまだ皆さんのクリエイティビティを後押しする機能があります。スクリプトの組み立て次第で、上手に使えば、今まで手作業だった工程を殆ど自動化できますよ。
 GitLab CIで使えるパラメータは、こちらの記事に掲載されていますので、その中から「これいいかも」というものを足していってください。

原文:https://docs.gitlab.com/ee/user/project/pages/getting_started_part_four.html
原文ページプロジェクト並びにドキュメントファイルは、MIT Licenseのもと公開されています。(URL:https://gitlab.com/gitlab-com/gitlab-docs/blob/master/LICENSE) この記事の文章は、訳者の判断によりCreative Commons BY (version 3.0) を適用するものとします。
新着文書(Hnoss)

GitLab Plugin system
GitLab Documentation > Administrator documentation >GitLab Plugin system GitLab 10.6より導入。  カスタムプラグインを使えば、GitLa...
UX Department
現在の位置: チームハンドブック 目次 >UX部門   UX ガイド  GitLabの見た目は、 UXガイド を基準に構成されている。このガイドが、わが...
Team Handbook
現在の位置:チームハンドブック 目次  このハンドブックは、GitLabという企業が、どのようにサービスを維持運営していくかを記したものだ。ここに...
Engineering
現在の位置: チームハンドブック 目次 >エンジニアリング   連絡方法 Public Issue Tracker (GitLab CEの場合) ; 不特定多数に公開して...

新着文書

Bristol’s Last Bookshop shares key facts on the remains of publishing
ブリストルの ラスト・ブックショップ (「最後の書店」)はたぶん、真の本好きのための残本店と言っていいだろう。それは、いくつかの出版社の名作...
Second social leader opposed to dam construction murdered in one week
一人の社会指導者は昨日プエルトリコ・バルディビアで虐殺された。これはアンティオキアで一週間以内に連続して起きた二回目の類似の殺人である。5月8...
Avianca strike leaders fired / Justice for Colombia
コロンビア第一の航空会社アビアンカは昨年9月20日から11月9日の長期にわたり行われたストに参加したパイロット14人を解雇した。解雇された一人、ハイ...

新着Wikipedia翻訳

Flutter (software)
Flutter -------- 原作者:Google 開発者:Googleとコミュニティ 最初の公開:アルファ(v0.0.6)/2017年5月;1年前(2017-05)[1] 試験版の公...
E (programming language)
E(プログラミング言語) AmigaE や e(検証言語) 、 GNU E と混同しないこと。 E -------- パラダイム マルチパラダイム:オブジ...
Van Eck phreaking
Van Eck phreaking(ファン・エック・フリーク) Van Eck phreakingは盗聴の一形態であり、その中では特殊な装置が使用され、電子機器を探るため、隠...

更新履歴

※文書量によっては処理に数十秒かかる場合があります
バージョン 比較対象 更新日時 更新者
1(最新) 2018-05-16 01:01:32 Hnoss
2 2018-05-04 15:02:19 Hnoss
3 2018-05-04 15:02:14 Hnoss
4 2018-05-04 15:01:17 Hnoss
5 2018-05-04 14:59:06 Hnoss
6 2018-05-04 14:56:16 Hnoss
7 2018-05-04 14:53:35 Hnoss
8 2018-05-04 14:52:19 Hnoss
9 2018-05-04 14:50:44 Hnoss
10 2018-05-04 14:50:35 Hnoss

    
ブックマーク登録

タグを「;(半角セミコロン)」区切りで入力して下さい(例)tag1;tag2;tag3
10タグまで登録可能。各タグ30文字まで

履歴
状態 作業中 作業予定あり 作業予定なし 作業完了
テーマ 社会 政治 法律 経済 文化 芸能 科学技術 IT 健康/医療 スポーツ メディア 植物 動物 菌類 地方 国際
地域 日本 東アジア アフリカ 南アジア 東南アジア 西アジア/中東 太平洋 北米 中南米 欧州
ジャンル ニュース 解説記事 論文 日記 百科事典

コメントを入力して下さい
0 / 250
    
ブックマーク登録

ブックマークに登録しました。


言語選択

    
ファイルプロパティ

使用許諾条件
ファイル情報
あなただけがこのファイルを閲覧・編集できます。
みんながこのファイルを閲覧できますが、
編集ができるのはあなただけです。
あなたに加えて、指定された人やグループが
このファイルを自由に閲覧・編集できます。
公開設定
編集設定
グループ:0組 翻訳者:0人
    
アクセス属性
この文書は「非公開」設定になっています。
一般公開する場合は、編集ページの書誌情報で「公開」設定に変更して下さい。
翻訳者選択

※メニュー「翻訳者管理」で翻訳者、グループを追加することができます。


    
ノート

非公開ノート
0 / 2000 ※「公開・編集」権限を持つ翻訳者のみに公開されます。
公開ノート
0 / 2000 ※文書を「公開」にした場合、一般に公開されます。

言語選択

 →