昨日会社でJenkins立てた時に .ssh/config が読めなくてハマってました。 読めなかった原因というのはJenkinsを動かしてるtomcat7ユーザのホームディレクトリ*1とJenkinsが見ているホームディレクトリ*2 が食い違ってたためなのですが、そこに至るまでの原因調査で非常に低レベルなトラブルシューティングをしてたので備忘録として残しておきます。 低レベルなトラブルシューティングとは？ ここでは「Jenkinsがシェルコマンドを叩いた時にどう実行できるか」を調べることを低レベルなトラブルシューティングとしてます。 Jenkinsをインストールしてるサーバにsshで入れれば sudo -u tomcat7 〜 でやるのが模範解答なのですが、今回は権限の関係でtomcat7ユーザになれなかったためJenkinsにシェルコマンドを実行してもらうことにしました どうやって？
Jenkinsのスクリプトコンソールを利用すると、Slaveで任意のコマンドを実行できます。具体的には、 RemotingDiagnostics.executeGroovy() メソッドを利用してSlaveでGroovyスクリプトを実行します。 import hudson.util.RemotingDiagnostics // Slaveノード名 def node = 'node-name' // 実行したいコマンド def command = 'uname -a' println RemotingDiagnostics.executeGroovy(""" def p = '$command'.execute() p.waitFor() println p.in.text """, Jenkins.instance.slaves.find { it.name == node }.chann
先日リリースされたJenkins Workflow Plugin 1.0を使ってみました。年明けのJenkinsユーザカンファレンスで詳しい発表があると思うので、今から楽しみですね！ Workflow Pluginでできること Workflow Pluginを使うと、Jenkinsジョブの動作をGroovyで記述することができて、さらにユーザとのインタラクションを差し込むことも可能です。これはデプロイメントパイプラインの実装に便利そうです。 また、リポジトリからチェックアウトしたGroovyスクリプトを読み込めるので、Travis CIやCircle CIのようにビルド設定をリポジトリで管理できます。開発現場でJenkinsを使い込んでいくと、いろんな人がジョブ設定をいじって荒廃していくことが多いので、ビルド設定をリポジトリで管理できることは大きなメリットがあると思います。 （と偉そうに書
弊社検証環境で半年ほど10数台規模のCassandraクラスタを運用してきたのですが、運用に使っているスクリプトがある程度固まってきたのでまとめてみます。更なる簡素化・便利化を進めるための棚卸しという感じです。古いものも混ざっていて若干申し訳なくはあるのですが……どなたかの役に立てば幸いです。では見て行きましょう。 スクリプトの運用体制について すべてのスクリプトはSubversionで管理され、主にJenkinsによって自動的に実行されます。多数のノードに対する同時処理を行なうためにGNU Parallelを使うことがあります。 またCassandraサーバはAWS EC2上で運用されているため、AWS SDK for RubyによってIPアドレスの取得などを行なっています。 各ノードでのnodetool ring実行結果を集約 クラスタが不安定なとき、実際は動いているのに一部のノードか
[Jenkins] Groovy postbuild plugin はとりあえずインストールしとけ
なぜ今まで使わなかったのか。もっと早く知っていれば、 チームメンバーからの要望に応えられてたというのに・・・ Groovy Postbuild Plugin 何が便利かJenkins が持っている情報の取得・変更がし放題なのです！ Jenkins をもうちょこーっとだけ便利に使いたいという場合に使えます。 例えば、このようなことに使えます。 [Hudson][Trac] ビルドへのリンクを自動で貼ってみた - ファイナル Jenkinsのジョブ失敗時にビルドを保存するスクリプト Cassandra運用に活躍したスクリプトたち ログから文字列検索してマッチしたら Unstable にする 使い方「ビルド後の処理の追加」から Groovy postbuild を選択、 「Groovy script」に処理を書きます。 例：テストの説明にビルド時刻を設定 def tr = manager.bui
![[Jenkins] Groovy postbuild plugin はとりあえずインストールしとけ](https://cdn-ak-scissors.b.st-hatena.com/image/square/f00620718017621ddae4cbc65638ed56a5e06b7a/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fproxy.goincop1.workers.dev%3A443%2Fhttps%2Fblogger.googleusercontent.com%2Fimg%2Fb%2FR29vZ2xl%2FAVvXsEgmU54sQDRL_aZtmZVI9FlSy4gUpK_WiA-AO-0Y43RsutMV_sx5YWgniPiXRsVcHlJiRMyLs_UQ40HKOQwFNTGe4U8QsU711vIZP9kzEvlBu1ikDexwXbyl0A6LKkc1z8JNI7jPs51EnAs%2Fw1200-h630-p-k-no-nu%2Ftest_time1.PNG)
This plugin is up for adoption! We are looking for new maintainers. Visit our Adopt a Plugin initiative for more information. NOTE The Job DSL Plugin is currently seeking co-maintainers. This does not mean that it's unmaintained right now, but that stepping up to help support this plugin would help long-term health of this project. Jenkins is a wonderful system for managing builds, and people love
TwitterとかFacebookのSNS疲れが著しいikikkoです。こんばんは。 最近久しぶりにGroovyを触ったので、生存確認の意味も込めてブログ書いておきます。 概要 Seleniumテストとかだと、実行時の画面のキャプチャを取っておきたいこともありますよね。で、せっかくキャプチャをとったはいいものの、そのキャプチャがどのテストに付随するものかがぱっと見分からないと、無駄な時間を過ごしてしまいます。 Jenkins上でテストを実行する前提として、Jenkinsのテストケースを表示する画面にそのテストケースで出力されたキャプチャが一緒に表示されると便利そうですよね。ということで、そんな設定をした画面を↓にお見せします。この画面を出すことが、今回のブログエントリの目標。 Jenkinsでテストケースとファイルの紐付 Junit Attachements Pluginを使えば、テストケ
MLであったJenkinsのGroovyスクリプトを書くにはどうしたらいいかという話。 JenkinsのAPIはプラグインを書いたりしてるとなんとなく分かった気がしてきますが、慣れていないとJenkinsを管理したり、Groovy Postbuildプラグインを使うときに困ります。 で、どうするのがいいかというと、やっぱり慣れるしかないかと思います。やりたいことは毎回違うし、よくやるような事はプラグインにしてしまえば良かったり、すでにプラグインになってたりします。MLであった環境変数を設定したいというのは色んな場面で使えそうなので、Groovy Postbuildプラグインで、 manager.addEnv('HOGE', 'ほげ') とか出来るようになればいいのかなと思ってます。そんな感じでプラグインが使いやすくなっていくと、Groovyスクリプトを書く機会が減って慣れてない人には敷居が
最近、すっかりJenkinsさんとご無沙汰なようなフリをして、実は邪道Jenkinsのやり方を模索していたりします。やってみたいことは、Jenkinsによるリモートジョブ実行とリモートサーバの監視などなど。「や、それならHinemosとかZabbix使えよ」とか言わない。 ジョブ実行はなんだかんだ言ってJenkinsさんの得意分野なので、じゃあ監視系はどうあるべきか？を考えてみた。ひとつは、[twitter:@akiko_pusu]さんが得意（？）にしている「外部ジョブの監視」。 → 外部ジョブの監視も使ってみよう！ これは、監視される側から監視して欲しい情報をJenkinsさんに送りつけるので、厳密な意味で監視と言えるのか疑問が残る（死活監視とか難しいよなと）。それと「外部ジョブの監視」はビルドの後処理とか仕込めないので、監視結果の通知とかする場合、もうひとつ知恵を絞らないといけなそう。
Jenkinsで「なんかうまく動いていない」「バージョンあげたらビルドが動かない」「Gitでcloneできなくなった」などのときに調査する方法でよく使うものをあげました。 具体的に何を調べればいいかはまた後日。 ログを見る 「http://{Jenkinsのデプロイ先}/log/all」にアクセスするとログが見れます。エラーが出ているときは大抵出ていますので確認します。 いろんなプラグインが実は裏でたくさんエラーログを出力していることがあるので、確認しておかしそうであればフィードバックしましょう。 ProcessExplorerを使う。 @kyon_mm Windowsならprocess explorerを使うと任意のプロセスの環境変数が確認できます。 2012-10-19 14:46:29 via TweetDeck to @kyon_mm ということで、Windowsではかなり便利です
今までであればインストールスクリプトも、Windows用のバッチファイル、Linux用のシェルスクリプトとそれぞれ作っていたのだけど、少しやり方を変えて、共通のGroovyスクリプトで実行できるようにしてみる。 メリットとしては、まずスクリプトが1本に収まることによる生産性、保守性の高さ。まがりなりにも一番長く触れてきた言語はJavaなので、親和性の高いGroovyなら、それ単独で見ても、バッチファイルやシェルスクリプトよりも効果的に開発できるし、バッチとシェルの違いに気をつけながらほとんど同じ振る舞いをするスクリプトを2つ作らなくて済む。 ちなみに今回、インストール対象のアプリは全てJava製で、JREも各インストール先に導入済み。そのため、GroovyならJREさえ入っていれば動くので、既存の環境に手を加えずにそのまま導入できる。インストーラを実行するために実行環境を新たに入れる必要は
明日は大阪で楽しくXPを体験してこようと思ってます、なおきりんです。（XP一日体験ワークショップ！ - http://kokucheese.com/event/index/30196/） 今回、継続的インテグレーションが参加するイベントの一つにあげられているので、先取りで独り継続的インテグレーション環境を作ることにしました。 ちなみに今回使っている環境は Mac OSX Lion (Mac book pro) JDK6（Mac上でのJDK7は挙動がまだ怪しいのでJDK6が安定のようです。2012/03/30現在） Groovy 1.8.6 Jenkins 1.454 Gradle 1.0-milestone-9 JUnit 4.10 spock-core-0.5 Git 1.7.7.5 となっています。蛇足ですがIDEはIntelliJ IDEAです！（ココ！重要！） Gradleでビルド
はじめまして！Ameba事業本部プラットフォームDivでアプリケーションエンジニアをしている池田(@yukung)です。 私は2011年5月に大手SIerから転職し、サイバーエージェントへ入社しました。前職では主に金融業界をターゲットにしたBtoB向けのシステム開発に多く携わってきましたが、開発作業の中でこんな経験を割とたくさんしてきました。 ・ソースコードやドキュメントの管理にバージョン管理ツールを使わずに、Hoge_yyyyMMdd.javaとかDB設計_yyyyMMdd.xlsみたいなファイル管理をしてどれが正しいドキュメントかわからなくなりカオスになる ・ソースコードの静的チェックツール（CheckStyleやFindbugsなど）を使わずに、目視と気合でひたすらソースコードレビューする ・Excel表で書かれたテストケースを睨みながら、手でケースに沿ったオペレーションをしてデバッ
このエントリーはStartup Scrumなブログではありません。Scrumというものに興味をもった当時23歳うさみみ系エンジニアがScrumという言葉を借りて開発してみた。という話です。2011/3から2011/5あたりの話。 2011/3。僕はデスマ４年目を終えて、新しいプロジェクトに移りました。 あるプロジェクトの中の4人チームのうちの1人として。もちろん僕はいちばん下っ端として。 （元請け会社の2人、当時同じ会社だった先輩、僕の4人） そのプロジェクトはWFだったんですけど、タイムボックスやリスク管理について理解があることは雰囲気で伝わってきました。 僕はその頃勉強し始めていたあらゆることを現場で試してみたいって強く思いました。 僕はMercurial、Jenkins、Groovyを趣味的に使い始めていて(MercurialとJenkinsは2010/10から。Groovyは201
groovyでJenkinsのジョブを実行する
groovyでJenkinsのジョブを実行するには、以下のコードを実行します。 @Grab(group='org.apache.httpcomponents', module='httpclient', version='4.1.2') import org.apache.http.client.methods.* import org.apache.http.impl.client.* import groovy.json.* httpclient = new DefaultHttpClient() // Jenkinsのジョブを実行する jobname = "test1" token = "MY_TOKEN" method = new HttpGet("http://localhost:8080/job/${jobname}/build?token=${token}") respons
Jenkinsではじめるビルド職人入門 著者 今井勝信 著 発売日 2011年11月18日 更新日 2011年12月13日
週の前半はトレーニング関係の準備を色々しました。事前の手配はアメリカからやったのですが、やはり現地でないとできないことも色々あります。また、ふと突然資料の一部を日本語に翻訳する気になって何時間かかけたり印刷したりと、自分で余計な仕事を増やした気もします。参加していただいた皆さんには有用だったとよいのですが、ぜひ率直なご感想をお願いします。 2/24はJGGUGのGroovyイベントに参加してきました。Jenkinsの中でどんな風にGroovyを使っているかという話を色々しました。 Jenkins と groovy その後の懇親会では、日本アンドロイドの会の宮田さんに小さな素敵アンドロイドデバイスを見せていただいたり、JRubyの有名人nahiさんとお話させていただいたりしました。自分の中ではまたGroovy熱が盛り上がってきたので、何かぜひやりたいと思っています。 翌日は、Jenkins勉
![[japan] 日本旅行まとめ - 川口耕介のブログ](https://cdn-ak-scissors.b.st-hatena.com/image/square/75d25754c78e36803d4e0c15e706ec1ca099e743/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fproxy.goincop1.workers.dev%3A443%2Fhttps%2Fogimage.blog.st-hatena.com%2F10257846132611268064%2F10257846132611268680%2F1534387838)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
