タグ

Jenkinsに関するmonochromeganeのブックマーク (17)

  • Jenkinsで高速にbundle installする方法 - Qiita

    はじめに JenkinsでRailsのテストやってますか? 肥大化するテストを高速実行するためにテストを複数のJobに分割するというのは有効な手段です。しかし、Railsのテストを行うためにはbundle installによるGemのセットアップが必須です。分割したJobが一斉にbundle installするとトータルでのテスト実行時間は極端に低下してしまいます。 ここでは、時間のかかるbundle installを高速に行うための解説を行います。 なぜbundle installは遅いのか? bundle installコマンドを叩くことで、bundlerはrubygems.orgから関連ライブラリをダウンロードしローカルにインストールします。しかし、GemによってはC言語で書かれたコードをコンパイルする事がありインストールに時間がかかります。また、複数Jobが一気にrubygems.

    Jenkinsで高速にbundle installする方法 - Qiita
  • How to give Jenkins more heap space when it´s started as a service?

    Ask questions, find answers and collaborate at work with Stack Overflow for Teams. Explore Teams Create a free Team

    How to give Jenkins more heap space when it´s started as a service?
  • Jenkinsでプルリクエストをビルドする - Qiita

    プラグインに設定オプションが多すぎて、設定の違いにより思い通りに動いたり動かなかったりしたので自分なりにまとめた。 基的にはまず以下のリンクを参考にしてセットアップしてください。 JenkinsプラグインのGitHub pull request builder pluginを使ってみる -> ビルドの結果のキャプチャあり(参考にしたソース、内容はほぼ同じ) Jenkins wiki - GitHub pull request builder plugin GitHub - ghprb-plugin 説明通りセットアップしたものの、自分のところではうまく動作しなかった部分を以降にまとめました。 GitHubの設定 個人とか少数で使う場合は必ずしも必要ない -> Jenkinsプラグインのジョブの設定でAdmin listに設定すれば良い Jenkinsプラグインのジョブの設定でList o

    Jenkinsでプルリクエストをビルドする - Qiita
  • Jenkinsプラグインを開発する - Qiita

    Jenkinsプラグインの開発〜ビルド〜インストールまでの手順をまとめました。 主に参考にしたのはここです。→https://wiki.jenkins-ci.org/display/JA/Plugin+tutorial 1. 前準備 mavenをインストールする 私はバージョン3.1.1を使いました。 古いバージョンだと開発での手順が増えるので、バージョンは最新を使った方が良いです。 Mavenのsetting.xml(apache-maven-3.1.1/conf/setting.xml)に下記を追記する <pluginGroups> <pluginGroup>org.jenkins-ci.tools</pluginGroup> </pluginGroups> <profiles> <profile> <id>jenkins</id> <activation> <activeByDefa

    Jenkinsプラグインを開発する - Qiita
  • JenkinsプラグインのGitHub pull request builder pluginを使ってみる - 技術めも

    現在、GitHubのPull Requestでコードレビューし、問題なければマージするというフローで開発しているのですが、 コードは問題なさそうなのでマージしてみると、specが落ちている・・といったことがありました。 そこで、Pull Requestされた時点でそれをマージしspecを実行してくれる、そしてその結果を通知してくれる といったことが自動でできれば良いなと考えていました。 そこで発見したのがGitHub pull request builder pluginというJenkinsのプラグインです。 このプラグインは、以下のようなことをやってくれます。 Pull Requestされた(またはそのPull Requestにコミットを積み重ねた)時にそれを検知し、自動でマージしビルドしてくれる (実際はcrontabで設定したタイミングで) GitHubのPull Requestペー

    JenkinsプラグインのGitHub pull request builder pluginを使ってみる - 技術めも
  • Jenkins Github pull request builder plugin 使う時にハマった事 - dunno logs

    いちいちコードレビューする前にビルドしてテスト実行するのがいい加減面倒になってきたので入れようとしてみました。以下のサイトを参考にさせてもらって設定したら、自前の環境だとサクッとキマったのに、どうも会社のアカウントだとビルドは機嫌よくいくのだけれど、終わった後のステータス更新が上手くいかない。。。 JenkinsプラグインのGitHub pull request builder pluginを使ってみる - 技術めも 最初は private repository だからかなーとか、organization の関係なのかなーとか思ってたのですが、Jenkins のログ見てると、どうも権限なくて失敗してるようでした。 Commit Status API Github 上のステータス更新には Commit Status API が使われています。 Commit Status API で、この A

    Jenkins Github pull request builder plugin 使う時にハマった事 - dunno logs
  • Dockerを使ってJenkinsのジョブごとにテスト実行環境を分離する - orangain flavor

    はじめに JenkinsでJVM上で動かない言語(PythonRubyなど*1)を使っていると、ジョブごとに環境が分離されていないことが問題になる場合があります。 Pythonにおける virtualenv やRubyにおける Bundler を使えば、ジョブごとに利用するライブラリを分離することができます。しかし、C拡張ライブラリをインストールするためには、ジョブが実行されるノードに開発用のファイルが存在している必要があります。例えば、Pythonモジュールの lxml のインストールにはlibxml2やlibxsltの開発用ファイルが必要です。 *2 このようなファイルが必要になるたびにJenkinsのノードにインストールするのはスマートじゃないですし、実行に必要な環境はコードの形で明文化されているべきです。 ジョブでaptやyumを使ってインストールするのもセキュアじゃないですし、

    Dockerを使ってJenkinsのジョブごとにテスト実行環境を分離する - orangain flavor
  • Rails Best Practices を CI (Jenkins) で確認する

    こんにちは。ほりいです。 今日は rails-bestpractices の話をします。 Ruby on Rails で開発するときのベストプラクティスをまとめている “Rails Best Practices”:http://rails-bestpractices.com/ というサイトがあります。先日の RubyKaigi 2011 で、このサイトのベストプラクティスに従っていないコードを指摘してくれる gem である “rails_best_practices”:https://github.com/flyerhzm/rails_best_practices についての “発表がありました”:http://rubykaigi.org/2011/ja/schedule/details/17S04 。 今回はそれを CI に組み込んでみた話をしたいと思います。 とりあえず rails_b

  • Jenkins に bundle update した上で Pull Request させる - @kyanny's blog

    皆さん bundle update してますか?ぼくは忙しさにかまけてついサボりがちなのですが先日何ヶ月ぶりかにやってみたらけっこういろんな gem がアップデートしててヒヤリとしました。 bundle update 忘れは今後もまたやってしまいそうだと思い、なにかこれを解決する方法がないか考えたところ、 マメにやるのは無理。余裕があればやるけど忙しくなったら忘れる。自分の意識が低くなっても破綻しない仕組みを作るべき 差分が小さくても Pull Request を出すのは悪くない。というか Pull Request は毎日全員が見るし放置されにくい bundle outdated の結果をメールするのもお手軽そうだけど、メールなんてどうせ見ない (pendaxes がいい例で、毎朝メールがきても痛くも痒くもない) ということで「Jenkins に毎週 bundle update したブラン

    Jenkins に bundle update した上で Pull Request させる - @kyanny's blog
  • ChefのrecipeをJenkinsで継続的インテグレーションする方法

    環境構築の自動化のツールとして一番注目されているのがChefです。 Recipeと呼ばれるインストールや設定のためのスクリプトを書いておき、それを使って新しいサーバを速攻で作ったり、Chef Serverを使えば複数のサーバ群に対して環境を一定に保つことが可能です。 ChefのRecipeは単なるrubyのスクリプトです。そしてrecipeでよく起こる問題として以下のようなものがあります。 外部サイトからtarballを取得してインストールしているような場合に、配布元の移転や、新バージョンの公開と旧バージョンの配布停止によって、recipeがコケるphpでよく使われるライブラリの配布形態であるpearのチャンネル情報が追加になったりURLが変更になる。インストールすれるパッケージがバージョンアップされ、依存関係が増えたりする。上記のようなことがあるので、recipeを定常的に動作確認してい

    ChefのrecipeをJenkinsで継続的インテグレーションする方法
  • Jenkins で静的解析のグラフを作るとコードを読まなくてもソフトウェアの品質が分かって面白い - おともだちティータイム

    細かく書きたいけど、とりあえずメモだけ。 ステップ数が増ている なんらかの開発が行なわれている ステップ数が減っている リファクタリングが行なわれている? 単に仕様落ちしたコードが削除された可能性もある テストカバレッジが下がる テストが書かれていない ... ステップ数が増えている場合 テストが減っている ... ステップ数が変わらない場合 FindBugs 、 PMD 、 Android Lint の警告数が増えている 品質の低下、レビューが正しく行なわれていない CPD 警告数が増えている 品質の低下、レビューが正しく行なわれていない そろそろリファクタリングしたほうがいい Checkstyle 警告数が増えている 品質の低下、レビューが正しく行なわれていない Jenkins で継続的にビルドしたり、テストを行なうのは言うまでもなく大切だけど、こういった静的解析の数値をグラフ化してい

    Jenkins で静的解析のグラフを作るとコードを読まなくてもソフトウェアの品質が分かって面白い - おともだちティータイム
  • JenkinsとSelenium WebDriverでUI層のテストも自動化&永続化する - プログラマでありたい

    思い立ったようにJenkins特集をしておりますが、今回はJenkinsとSelenium WebDriverでUI層のテストの自動化をする話です。Seleniumは面倒臭い画面のテストを自動実行してくれるツールで、出てきてからもう7〜8年がたちます。Web系の開発に携わっている人であれば、一度は試したことがあるのではないでしょうか?そして、必ず挫折したことがあると思います。 その理由としては、せっかく作ったSeleniumのテストケースが腐ってくるからです。一般的にはUI層の変更は、ロジック層に比べて変化が激しいです。だからこそテスト自動化して保証することに意味があるのですが、そのテストケースを維持するのは大変です。そこで、Jenkinsの登場です。Jenkinsでサーバサイドで継続的に実行することにより、Seleniumのテストケースが成功を保てるようにします。また、複数のブラウザ・バ

    JenkinsとSelenium WebDriverでUI層のテストも自動化&永続化する - プログラマでありたい
  • [MAC]jenkinsインストール設定 | Coffee Breakにプログラミング備忘録

    macにjenkinsをインストールする手順をメモ パッケージ管理はhomebrewを使う インストール brew install jenkins インストール確認 brew list jenkinsインストール情報(バージョンなどの確認) brew info jenkins 起動 •手動起動(毎回起動する必要がある) java -jar /usr/local/cellar/jenkins/1.496/libexec/jenkins.war •自動起動(MAC起動時に自動実行) launchctlというサービスの登録・管理が可能なものを使用する ln -sfv /usr/local/opt/jenkins/*.plist ~/Library/LaunchAgents launchctl load ~/Library/LaunchAgents/homebrew.mxcl.jenkins.pl

  • 同僚の外国人プログラマ観察記録 - rinu's blog

    概要 1ヶ月くらい一緒にお仕事している外国人プログラマさんを観察した記録です。 スペック 性別: 男性 仕事内容: うちの会社のプログラマは、ざっくり JS 等のフロントエンドと、 Java 等のバックエンドエンジニアにわかれているのですが、彼はどちらもやっているようです。 好きなべ物: はちみつ たまに、くまさんのようにはちみつを舐めていました。 性格 彼はめんどくさがり屋です。 同僚の Windows ユーザの手伝いをしている時、 "C:¥Program Files¥..." みたいなパスを打ちながら、「めんどくさい。 ああ めんどくさい」 と 100回くらいつぶやいていました。 (普段の彼の環境は mac なので /usr/local/bin) パスワードを覚えるのもめんどくさいので 1Password で管理しているようです。 PC スペック マシン: Macbook Pro メ

    同僚の外国人プログラマ観察記録 - rinu's blog
  • Jenkinsで外部パラメータで与えたブランチを対象にビルドできるようにしておくと凄惨性あがって墓ドル - ( ꒪⌓꒪) ゆるよろ日記

    テストが終わるまでの時間で書いてみる。 Jenkinsでジョブを実行させるときに、外部パラメータで任意のブランチを対象にビルドできると墓ドル。 例えば、自分のローカルブランチをマージするまえに、テストが通るか確認したい場合とか。 そんなのローカルでテストすりゃーいいじゃんって言われるかもしれないが、 テスト全部通すのに時間が掛かるようになってると、とりあえずCIに実行を投げておいてあとで確認するほうがずっと効率がいい。 F.Y.I: Building github branches with Jenkins ジョブの設定 「ビルドのパラメータ化」にチェックをつけて、以下のようにbranchって名前のパラメータを設定しておく。 「ソースコード管理システム」で「Branches to build」のところに、設定したパラメータである"$branch"を入れておく。 ジョブの設定は以上。上記の方

    Jenkinsで外部パラメータで与えたブランチを対象にビルドできるようにしておくと凄惨性あがって墓ドル - ( ꒪⌓꒪) ゆるよろ日記
  • Gerrit trigger pluginを使ってjenkinsをコードレビューシステムgerritのレビューアーにしてみよう

    Gerrit trigger pluginを使ってjenkinsをコードレビューシステムgerritのレビューアーにしてみよう 1. Gerrit Trigger Pluginを使ってJenkins をGerritのレビューアにしてみよう 第6回Jenkins勉強会 2012/10/19 太田 健一郎 @oota_ken 2. 目次 自己紹介 書籍「入門Jenkins」の紹介 エンタープライズ開発でありがちなレビュー Jenkinsによる自動レビュー Gerritによる手動レビューのワークフロー自動化 Gerrit + Jenkins ~Jenkinsをレビューアに~ 3. 自己紹介 経歴  社内まったりツール開発 5.5年 (JavaScript & Perl)  お客様デスマソルジャーSE 4年 (主にJava、一部COBOL)  ソーシャルゲームQA 1.5年 (

    Gerrit trigger pluginを使ってjenkinsをコードレビューシステムgerritのレビューアーにしてみよう
  • GREEにおけるJenkins, その2 | GREE Engineering

    こんにちは、エンジニアの岡崎(@watermint)です。今回はGREEにおけるJenkinsをつかった品質管理について紹介します。 hourlyビルド 岡崎がGREEに入社したのは1年半前ですが、そのときから感じているのがGREEの開発速度は非常に速いことです。ソースコードレポジトリには多くの優秀なエンジニアが日々数百以上のコミットしています。 GREEのシステムは多くのサブシステムを組み合わせたものですが、手元の些細な変更が全く予想しない別のプロジェクトで問題を起こすことがあります。こういった問題は通常、リリース前の結合テスト等の段階で検出します。 リリース前のテストで問題が発覚すると、当然その修正をして再度修正をリリースプロセスにのせるということになるのですが、これには他のエンジニアの作業を止めてしまったりリリースの順序を調整が必要になることがあります。 こういった事態を防ぐために単

    GREEにおけるJenkins, その2 | GREE Engineering
  • 1