サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
体力トレーニング
tyuki39.hatenadiary.org
はじめに Hudsonのコミュニティは非常に活発で、2010/12/29時点で380以上のプラグインがGitHub - Hudsonに登録されています。 プラグインの洗練度には差があるものの、Hudsonをより効果的かつ効率的に利用するためには、開発業務にあったプラグインを上手に使いこなすことが不可欠ではないかと思います。 そこで、この記事では各プラグインを紹介する前に、基本事項ではありますが、プラグインのインストールについて説明します。 プラグインをインストールする前に プラグインファイルの準備(自動インストールでは不要) 外部から隔絶されたネットワーク環境にあるマシンにプラグインをインストールする場合や、プラグインの公式ダウンロードサイトに登録されていないプラグインをインストールする場合は、プラグインファイル(*.hpi)をダウンロードしておくか、GitHub - Hudsonに登録さ
はじめに Jenkins Advent Calender 2011 16日目担当の id:tyuki39(@tyuki39) です。 小ネタを物量でカバーする形になって恐縮ですが、よろしくお願いします。 なお、前の日は id:ssogabe さんの「Karotzさんといっしょ」でした。 ビューにカラムを追加しよう! 皆さん、Jenkinsのビューを活用しているでしょうか? デフォルトの【すべて】ビューだけを使っている、なんてことはないですよね? Jenkinsのトップページにアクセスしたとき、または、マイビューにアクセスしたときに、 ・ 自分自身が関わっているジョブの状態がさっと一覧され、 ・ 設定画面がさっと開けたり、 ・ 失敗の原因を探るべく失敗ビルドのコンソールがさっと開けたり すると便利です。 Jenkinsのプラグインの中には、そんなニーズに応えてくれて、ビューをもっと使いやすく
はじめに 昔書いたバッチファイルとシェルスクリプト(sh系)の比較情報を見つけたので、役に立たないなと思いつつネットに晒してみます。 カレントディレクトリの取得 カレントディレクトリの取得方法は次のとおりです。 バッチ シェル 環境変数 CD で取得 環境変数 PWD で取得 空行の出力 ログを見栄え良く出力するために空行を出力する場合は、次の方法を用います。 バッチ シェル ECHO の直後にドット(.)を記述 echo のみを記述 算術式の評価 コマンド実行回数のカウントアップやカウントダウンなどの簡単な演算を行いたい場合は、次の方法を用います。 バッチ シェル SETコマンドを /A オプション付きで実行 exprコマンドを実行 日付と時刻の取得 実行ログの名称に日付や時刻を含めることがよくあります。 日付と時刻の取得方法は次のとおりです。 バッチ シェル dateコマンドのフォーマ
Groovyでテンプレートエンジン - No Programming, No Lifeで紹介されているとおり、Groovyではテンプレートエンジンと呼ばれるものが使えます。 このテンプレートエンジンを使っていて、改行のみの不要な行が出力されることに悩まされていたのですが、テンプレートファイル側を調整することで解決できたのでメモしておきます。 テンプレートの呼び出し側のコード(共通) def f = new File('sample.template') def engine = new groovy.text.SimpleTemplateEngine() def binding = [ 'title' : '', 'items1' : [], 'items2' : [], ] binding.title = 'サンプル' binding.items1 = [ 1, 2 ] binding.
はじめに HudsonをWindowsサービスとして起動した場合に、Hudsonがシステム環境変数で設定した「HUDSON_HOME」を使用していないように見受けられたため、「HUDSON_HOME」の決定要素と決定順序について調査し、変更する際の一助になればと思いまとめました。 「HUDSON_HOME」の決定方法は、Administering Hudson - HUDSON_HOMEディレクトリに記載されていますが、以下はこの内容にWindows環境向けの情報を加筆したものになります。 以下では、Hudsonの起動方法の違いを簡易的に表現するためのアイコンを用います。 : Hudsonをコマンドシェルから起動することを表します : HudsonをWindowsのサービスとして起動することを表します : HudsonをTomcatに配備して起動することを表します HUDSON_HOMEデ
はじめに 最近ドキュメントの整備が最優先重要課題になってきたので、ドキュメントを効率よく書くための方法を調査していました。 年初くらいから調査していて、 「ドキュメントを作りたくなってしまう魔法のツール Sphinx」 とか 「遷移図生成ツール blockdiagの紹介]」 とか 「本当のドキュメントと向き合えますか」 を見て ようやく「Sphinxにしよう!」と決心したので、Windows環境にSphinxを導入してみました。 そこで、この記事ではWindows環境にSphinxを導入するための手順を紹介したいと思います。 記事の作成にあたって、次のサイトを参考にさせていただきました。 「blockdiag を WindowsXP で動かす」 「OmakeでSphinxを自動継続ビルドしてみよう」 目標 この記事では、次のことが実現できる環境を構築します。 Sphinxを使って、テキスト
はじめに システムレベルのお話 Jenkinsのページのうち、参照頻度の高いページが少し深い階層に存在していることがあります。Permalinkが設定されているページであれば、ビューの説明欄にそのページへのリンクを記述して、階層を浅くすることができます。 この説明欄を用いる方法は、表現力が高く、柔軟にカスタマイズできるところが魅力ですが、ビューごとにリンクを記述する必要があるので、複数箇所に同じリンクを記述したい場合に少し不便です。 プロジェクトレベルのお話 開発プロジェクトで情報共有用サイトを運用している場合、そのサイトにJenkinsへのハイパーリンクを記述しているのではないでしょうか。しかし、その逆(Jenkinsからサイトへ)はというと、サイトへのリンクを設定していない場合が多いのではないかと思います。 ここで上記と同様に、プロジェクトの説明欄にそのサイトへのリンクを記述して、相互
はじめに Jenkinsにジョブを登録していくと、ジョブを何らかの目的別に分類したくなってきます。例えば、「開発案件AAAに関するジョブたち」、「開発案件BBBに関するジョブたち」、「失敗ビルドに関するジョブたち」などに分類することが考えられます。 このような場合、Jenkinsでは新たなビューを作成して、そのビューに目的別に分類したジョブを所属させます。 ジョブの数が少ない場合やマメな人が多い場合は、新しいジョブを作成する方法で十分運用できます。しかし、目的別のビューを一つ一つ作成していくのは、結構退屈で地味に手間のかかる作業です。 そこで、この記事では、このような状況を改善するための一手段としてFavoriteプラグインを紹介したいと思います。 なお、このプラグインは、簡潔に述べると、 ジョブを「お気に入り」に追加したり、 ジョブを「お気に入り」から削除したりして、 ビューに表示したい
はじめに ほとんどディスクを消費しないジョブもあれば、一度のビルドでかなりディスクを消費するジョブもあります。 「ギリギリだけど、なんとかなると思っていたら、ディスクフルになってしまった」、「いつもと違うノードが動いて、ディスクフルになってしまった」などといったことが発生するかもしれません。 そこで、この記事では、このような状況を改善するための一手段としてDisk Usageプラグインを紹介したいと思います。 なお、このプラグインは、簡潔に述べると、 ジョブごとに ビルドを実行したノードの「workspaceディレクトリ」または マスターノードの「buildsディレクトリ」が どれだけディスクを消費しているのか を調査するための機能を提供します。 インストール Disk Usage Pluginの名称と関連URLは次のとおりです。 プラグイン名 Wiki URL ダウンロード URL Gi
はじめに 「誰かがジョブの設定を誤って変更してしまったため、昨日まで問題なく動いていた自動ビルドが失敗してしまい、問題の特定に時間がかかってしまった」なんてことになると面倒です。 このような場合、「過去の設定」と「現在の設定」が簡便に比較できるようになっていると、問題点を短時間で特定できて助かります。 そこで、この記事では、このような状況の改善策の一手段としてJobConfigHistoryプラグインを紹介したいと思います。 なお、このプラグインは簡潔に述べると、 いつ 誰が 何の設定を どのように変更したのか を調査するための機能を提供します。 インストール JobConfigHistory Pluginの名称と関連URLは次のとおりです。 プラグイン名 Wiki URL ダウンロード URL GitHub URL JobConfigHistory Plugin http://wiki.
はじめに Hudsonを標準状態のままで使用した場合、Hudsonにアクセスできる全てのユーザが、Hudsonの全ての機能を制限なく利用できてしまいます。 Hudsonの機能を熟知しているチーム内でHudsonを使用するのであれば、この標準状態の方が設定に煩わされない分、簡便に運用できるので都合が良いかもしれません。 しかし一般的には、間違った操作によってHudsonが動作しなくなることを防ぐために、「Hudsonの管理者」と「Hudsonの利用者」くらいの最低限の区別をした方が良いのではないかと思います。 そこで、この記事では、Hudsonのユーザーデータベースを使用して、Hudsonの操作権限を制御する方法について説明したいと思います。 なお、説明を簡素化するために、Hudsonの公式サイトにはない用語や分類を用いて説明していますので、その点はご了承ください。 操作権限を制御する前に
はじめに リリースに向けて追い込みに入っている状況なのに、マーフィーの法則が予定どおりに(?)働いて、「昨日まで動いていたHudsonがハードディスク故障のせいで動作しなくなっている」なんてことになると大変です。 この記事では、そんな状況でも慌てず騒がず対処できるようにするために、Hudson環境のバックアップについて説明したいと思います。 なお、この記事におけるバックアップ方針は次のとおりです。 (A) : お金をかけずに取得する (B) : 安全なタイミングで取得する (C) : 分かりやすい方法で取得する (D) : Hudson自身に(定期的に)取得してもらう バックアップの前に バックアップ対象 バックアップ対象は、Hudson環境が構築されているHUDSON_HOMEディレクトリの内容になります。 (HUDSON_HOMEディレクトリ内のディレクトリ構成例は以下を参照) HUD
このページを最初にブックマークしてみませんか?
『ふぞろいのGENGOたち』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く