[Jenkins] Gitのsshでのクローンが失敗する場合の解決法メモ - Qiita
毎回セットアップ時に引っかかる点のメモ todo: ログ取り忘れたので追記する 前提知識 Jenkinsは jenkins ユーザーでcloneを行います。 そのためJenkinsが参照に行く~/.ssh/config は /var/lib/jenkins/.ssh/config などになります。 ~/.ssh/configがない jenkinsユーザーになって ~/.ssh/config を作成する $ sudo su jenkins # 以下は gitlab での例 $ ssh-keygen -t rsa -N "" -f ~/.ssh/id_rsa_gitlab $ cat << EOS >> ~/.ssh/config Host gitlab User git Hostname gitlab Port 22 IdentityFile ~/.ssh/id_rsa_gitlab EOS
![[Jenkins] Gitのsshでのクローンが失敗する場合の解決法メモ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/fdb8e101d228fe7538b049cb65cd4e83c40dd304/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCSmVua2lucyU1RCUyMEdpdCVFMyU4MSVBRXNzaCVFMyU4MSVBNyVFMyU4MSVBRSVFMyU4MiVBRiVFMyU4MyVBRCVFMyU4MyVCQyVFMyU4MyVCMyVFMyU4MSU4QyVFNSVBNCVCMSVFNiU5NSU5NyVFMyU4MSU5OSVFMyU4MiU4QiVFNSVBMCVCNCVFNSU5MCU4OCVFMyU4MSVBRSVFOCVBNyVBMyVFNiVCMSVCQSVFNiVCMyU5NSVFMyU4MyVBMSVFMyU4MyVBMiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1jbGlwPWVsbGlwc2lzJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9NWFkNTQzMGU5NTJkYzE1MDAwNDYyMWM5ZWJkNjZhZGQ%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwa29hcmEtbG9jYWwmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTJiNTJlZjViMDI3MmJiYjMzYzIxODJhZWE5ZGYzMDQ3%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D641788e82ac240b27fbaa30fdc94e1d5)
人気CIツール比較まとめ【2015年12月版】 - Qiita
概要 こんにちは。本日の担当の@hiro_kobaです。リブセンスでアクセスログ分析基盤の開発等をやっております。 本日は最近人気のある5個のCIツールを、色んな角度から比較してみようと思います。 背景 テスト環境でテストを実行し、通ったらステージングにデプロイ、その後動作が確認できたら本番デプロイ。 日々のオペレーションでよくある光景かと思いますが、手動での手順が多いためミスが発生しやすく、かつ手間も掛かるため、課題を感じておりました。 これらの継続的な運用フローを自動化してくれる仕組みとして、CIツールがあります。 CIツールは大きく分けて、以下3つに分類されるようです。参考 Everything（全方位型） Build, Test and Delivery（ビルド・テスト・デプロイ特化型） Specialization（その他特化型） 今回の問題には「Build, Test and
ぼくとJenkinsおじさんの360日戦争
イベント「EventStormingワークショップ 〜かつてない図書館をモデリングしてみよう〜」 の説明資料です。 Big Picture Workshopのやり方を解説しています。 This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis
Introducing Blue Ocean: a new user experience for Jenkins
In recent years developers have become rapidly attracted to tools that are not only functional but are designed to fit into their workflow seamlessly and are a joy to use. This shift represents a higher standard of design and user experience that Jenkins needs to rise to meet. We are excited to share and invite the community to join us on a project we’ve been thinking about over the last few month
CIでの確認項目 - 弥生開発者ブログ
こんにちは、Misoca開発チームのmzpです。 GWは日光に遊びにいっていました。 MisocaではJenkinsを利用してCIによる自動テストを行なっています。最初はrspecを実行するだけのシンプルなものでしたが、都度設定を追加し、様々な項目をCIで確認するようになっていきました。 今日はそのCIで確認している項目について紹介したいと思います。 確認している項目 静的解析 コーディングスタイルのぶれや脆弱なコードを書かないようにするために、各種静的解析ツール(Rubocop、HAML-Lint、Brakeman)を導入し、警告がでないことを確認しています。 導入した直後は違反箇所の一覧を作成するのみで、ジョブの成否とは無関係でした。しかし、だんだんと違反箇所の修正をしなくなってしまったので、今は違反箇所がある場合はジョブが失敗する設定にしています。 rspec 全specの実行はrs
イマドキのIDE事情 第137回 Travis CIとBuildHive、オンラインCIサービスを活用しよう - たけぞう瀕死ブログ
IDE連載の第137回です。今回はオンラインCIサービスということでTravis CIとBuildHiveを紹介させていただきました。「IDEじゃないじゃん！」という突っ込みが入りそうですが、開発環境に関するトピックを幅広く取り上げさせていただくということでご容赦いただければと思います。 http://news.mynavi.jp/column/ide/137/index.html Travis CIとBuildHiveはどちらもGithubと連携したオンラインCIサービスという点ではよく似ていますが、細かい部分を比較すると、Travis CIは独自の設定ファイルをリポジトリにコミットしておく必要があるものの対応言語が多くクロスバージョンでのビルドが可能など柔軟性も高そう、という印象です。これに対してBuildHiveはプロジェクトの構造から自動的に最適なテンプレートを使用してジョブの設定
Android SDKでビジネスロジックのテストを自動化するには
Android SDKでビジネスロジックのテストを自動化するには：Androidアプリ開発テスト入門（2）（1/3 ページ） ビジネスロジックのテスト自動化から始めよう 本連載ではAndroidアプリを開発している方のためにテストの基本的なノウハウを解説しています。前回の「Androidアプリ開発でテストを始めるための基礎知識」では、Androidアプリ開発におけるテストの課題を解説し、EclipseとJUnitを使った単体テストのやり方を環境構築やコードの書き方を含め紹介しました。今回は「ビジネスロジック」のテストについて説明していきます。一口にビジネスロジックといっても読者の皆さんが持つ定義は、さまざまかと思います。 Android開発におけるビジネスロジックとは 本連載ではビジネスロジックを「Androidのシステムに依存しない独立した処理」と定義します。具体的には文字列処理や日付・
JenkinsでCI（継続的インテグレーション）すればAndroidアプリ開発はもう怖くない
JenkinsでCI（継続的インテグレーション）すればAndroidアプリ開発はもう怖くない：Androidアプリ開発テスト入門（6）（1/2 ページ） 日本Androidの会テスト部が、いままで培ってきたAndroidアプリ開発におけるテストのノウハウを、実際のテストコード例とともに紹介していきます 本連載「Androidアプリ開発テスト入門」では、Androidアプリを開発している方のためにテストの基本的なノウハウを解説しています。第6回では、CIツールである「Jenkins」を用いてAndroidをテストする方法を解説します。 いまさら聞けない「継続的インテグレーション（CI）」とは 「継続的インテグレーション」（以下、CI）とは、アジャイルのベストプラクティスの1つで、「すべてが自動化された再現可能なビルド・テストを日に何度も行うこと」です。 CIのメリットには、次のものがあります
継続的インテグレーションを始めるための基礎知識
継続的インテグレーションを始めるための基礎知識：グリーはいかにしてJenkinsを導入したのか（1）（2/2 ページ） どのCI製品／サービスを利用するかの3つのポイント どの製品あるいはサービスを使うか最初は、次のような視点で考えると良いでしょう。 【1】導入が簡単か まだCIを実施したことがないようであれば、ツールを導入するだけのために多くの労力をかけるよりもまずは導入して、経験を積むべきです。多機能／高機能であるよりも、まずは導入が簡単であるかどうかを判断基準にすると良いでしょう。 CIツールのためのサーバを用意できないようであれば、クラウドサービスの利用も選択肢として考えられます。 【2】サポート体制について CIを開発に取り入れるためには、手厚いサポートが欠かせません。オープンソース製品であれば、コミュニティがどの程度活発に活動しているかを確認しておくと良いでしょう。 【3】連携
またjenkinsの設定をバージョン管理してみたい人が現れた - Qiita
jenkins 2.0をgitでバックアップ・復元する話です。 jenkinsとバージョン管理 jenkinsはcronの代替品や、エンジニア以外の人にバッチ処理を走らせるための手軽なwebインタフェースとしてはかなり便利です。万が一のために、jenkinsをバックアップ・復元するソリューションもほしいですが、そういった標準機能は未だに存在していません。 大規模のjenkinsならVMイメージやdocker、どちらかと言うとインフラ構成管理のやり方でなんとかなるだろうけど、たった一台のjenkinsの場合、もっと手軽なソリューションがほしくなりますね。できればファイル同期すれば新しいディレクトリーに展開できるようにしたい。というわけで、真っ先にgitに思いつきます。 しかし、jenkinsの設定をgitで管理するには若干強引なところがあります。commitする範囲をファイル名やディレクトリ
Jenkins 2.0 is here!
Over the past 10 years, Jenkins has really grown to a de-facto standard tool that millions of people use to handle automation in software development and beyond. It is quite remarkable for a project that originally started as a hobby project under a different name. I’m very proud. Around this time last year, we’ve celebrated 10 years, 1000 plugins, and 100K installations. That was a good time to r
Jenkinsと完全にサヨナラして、CircleCIに移行した話 - tehepero note(・ω<)
2015-07-02 Jenkinsと完全にサヨナラして、CircleCIに移行した話 CI Jenkins CircleCI 長らくCIはJenkinsを利用して開発をしてきて、Hudson時代からご愛顧してきたのですが、この春から新しくスタートしたプロジェクトではJenkinsを利用しないという決断をしました。 Jenkinsとサヨナラした理由 複数プロジェクトで共有して利用するのがツライ うちの会社では共通で用意されたJenkinsがあって（それなりにスペック高くて、slaveもぶら下がってる）、色々なプロジェクトがそれを利用しています。 このケースの問題点は何よりもランタイムやSDKを共有してしまうことにあります。全てのビルドに副作用を与えることなく、ランタイムやSDKを追加・更新するのが簡単ではありません。それを滞りなくやるには事前にどのビルドが何を使っているかを把握したり、利用
無料でbitbucketのリポジトリをCI - Qiita
ゴール bitbucketのレポジトリにpushしたら、jenkinsに通知されてビルドが実行される 使うもの CloudBees (javaのpaasサービス / 最初からjenkins入ってる) 手順 ステップ1. まずは手動でbuildするところまで設定 CloudBees側 CloudBeesアカウント取得 jenkins(すでにインストールされてる)を起動(10分位かかる) 新しくビルドジョブを作成 ソースコード管理のURLを記入 例) git@bitbucket.org:XXXXX/XXXX.git ビルド手順を設定(テストの実行とか) CloudBees Public Key※1を手元にコピーしておく BitBucket側 アカウント設定設定画面からssh key※1を登録 注)レポジトリの設定ページの”デプロイ鍵”に設定しても手動ビルドは通るが、 pushを検知してbuil
Google Test ユーザーが Boost.Test を使ってみた
この記事は、C++ Advent Calendar 2012: 17日目の記事になります。 お題は「Google Test ユーザーが Boost.Test を使ってみた」です。 (2012/12/27: 補足記事を書きました。) これまで、C++ の testing framework には Google Test を使ってきたのですが、 この機会に Boost.Test に挑戦したいと思います。 今年２月に行われた「Boost.勉強会 #8 大阪」の参加報告で Boost.Test 使うぜ！っと意気込んでおいて今更かという感じではありますが・・・ では、なぜ今まで使わなかったのかというと boost の導入がめんどくさそう 日本語情報が少ない Google Test が使いやすかった と、いう勝手なイメージがあったからです。最後のが一番大きな理由でした。 でも、他のフレームワークのこと
JenkinsのGit Pluginの設定の意味がやっとわかった - Qiita
JenkinsでGitを使う時にはGitPluginを使うと思いますが、この設定の細かな意味がわからずにいたのですが、いい加減本腰で調べてみました。 GitPluginの設定ではビルド対象のブランチを指定します。 ここでは複数のブランチを指定できるのですが、１つのジョブで複数のブランチを指定するとどれが対象になるのでしょうか？また、ある特定のブランチを明示的にビルドするにはどうすればいいでしょうか？ 動作を調べたところ、このブランチ設定は「ビルド対象ブランチ」というよりも「更新監視対象ブランチ」と言った方がよさそうです。 実際の動作は以下のようになっているようです。 ジョブが実行される Gitをfetchし、リモートブランチの状態を収集 以下の手順でビルド対象ブランチを収集する [Branches to build]の設定（対象ブランチ設定）が１つだけで、その定義(変数は展開済み)が明確な
これが大規模SIerな弊社のデファクトスタンダードな開発スタイルだ！！ - そこに仁義はあるのか(仮)
受託開発やっている、いまの開発スタイルを書く。 この前のブログはわりとフォーカスをしぼったはなしだったので、今回は簡単に全体のはなし。（書く順番が逆っぽい） 今回のプロジェクトではアーキテクトとして、この↓開発スタイルの構築と運用をしていて学び多い。 バージョン管理はGit プロジェクト用サーバーにGitBucketをたててソースコードを管理している。 オフショアと仕事をするなど、開発拠点がわかれることが多い。 ソースコードに対してロックをとったりしちゃうと、他の人が開発すすめられなくなるし、拠点別れて並行開発する大規模案件だからこそ、Gitを使う必要がある。 各開発者がブランチをきって開発をして、プルリクでレビュー依頼、からのマージをすることで、レビューが済んでいるソースしかmasterブランチに取り込まれない、というのもイイ。 弊社の”エンジニア”はみんな当たり前のようにGitを使って
イマドキのIDE事情(137) Travis CIとBuildHive、オンラインCIサービスを活用しよう
Jenkinsによる継続的インテグレーション ここ最近、継続的インテグレーション (CI)ツールであるJenkinsが大きな注目を集めている。継続的インテグレーションとは、ソフトウェアのビルドを定期的に実行することでコンパイルやテストが通らないといった問題を早期に発見するというものだ。CIは自動化されたビルドスクリプトさえ用意すれば開発言語を問わず導入することができ、既存の開発環境や開発プロセスにドラスティックな変化を必要とせずに導入できるため敷居も低い。 JenkinsはわかりやすいWebベースのインタフェースを備えており、手軽に導入できるという点が大きなメリットだが、ことオープンソースプロジェクトに関してはより手軽にCIを実現する選択肢が存在する。それがオンラインサービスとしてCIツールを提供しているTravis CIやBuildHiveだ。 Travis CIはオンラインCIサービス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Jenkinsではじめる継続的インテグレーション
いぬごやねっと
MACへJenkinsをインストール(インストールの仕方編) - Qiita
