Jenkinsの文字コードを設定する方法 特に指定を行っていない場合は、OSの文字コード設定に合わせた文字コードが選択される。 CentOSの文字コード設定方法 OSの設定とは異なる文字コードを使用したい場合は、以下の方法で設定する。 /etc/sysconfig/jenkinsへプロパティ「JAVA_ARGS」を設定。
顛末 事象 Jenkinsそのものは、文字化けたりすることはなく使えている。 JenkinsのジョブでChatworkAPIを叩いてメッセージを投稿したら、投稿された内容が文字化けして読めない。 原因 Jenkinsの文字コードが正しく設定されていない。 OSの文字コードが正しく設定されていない。
継続的インテグレーションの手順のうち、デプロイに焦点を当てて、テストの実行から、GitによるHeroku環境へのデプロイまでを自動化する方法を解説。Mac向けのGrowlを使って実行結果を通知する方法も説明。 ← 前回 連載 INDEX 次回 → 連載第1回「Jenkinsを使ってみよう」ではMac(OS X)/Linux/Windowsへのインストール方法を、第2回「Jenkinsでテストを実行してみよう」ではユニットテストおよびインテグレーションテストを作成し、Jenkinsから実行する手法を解説した。ここまで読んでいただいた読者の皆さんもJenkinsをインストールして自分なりの使い方を模索していることと思う。 さて、連載第1回で「継続的インテグレーションとは次のような手順の繰り返しだ」と説明したのを覚えているだろうか? プログラミング テストの実行 リファクタリング デプロイ 今回
Jenkinsでは、JUnitのテスト結果からテスト件数や実行時間などを集計することが出来ます。この時、JUnitの実行結果はXML形式のファイルとして出力され、「JUnitのXMLファイル」などと呼ばれています。ところが、このXMLのフォーマットは、JUnitの公式フォーマットではありません。JUnit自体には実行結果をXML形式に出力する機能は実装されていないため、Ant, Maven, Gradleといったビルドツールによって出力されています。恐らくはAntが出力していたJUnitの実行結果のXMLフォーマットに、Eclipseなどの他のツールが対応していき、結果としてデファクトスタンダードとなったと思われます。 Jenkinsでは、デフォルトでJUnitのXMLを集計できるため、他のテストツールを使ってテストを実行した場合にも、JUnitのXML形式に変換すれば、簡単にJenkin
Jenkinsはジョブを実行するだけでなく、結果を集計する機能にも優れています。Jenkinsには標準でJUnitの結果を集計する機能が付いており、これを応用すると、複数サーバで実行したジョブの結果を分かりやすく表示するといったことが簡単にできます。 複数サーバで同じジョブを実行するには Multi-configuration Project を使います。ジョブの設定で、実行したいサーバにチェックを入れると、同じスクリプトが指定したサーバで実行されます。そして、後処理に「JUnitテスト結果の集計」を追加すれば結果を集計することも可能です。 例として、各サーバの設定ファイルをdiffでチェックするジョブを考えてみましょう*1。 リポジトリからお手本を取得した後、お手本とサーバの設定ファイルを比較するスクリプトを実行します。こんな感じ。 find . -type f | cut -d/ -f
1.544 APサーバ Tomcat 7.0.42 インストール war ファイルのダウンロード Welcome to Jenkins CI! | Jenkins CI にアクセスして、 war ファイルをダウンロードする。 JENKINS_HOME の設定 環境変数 JENKINS_HOME を設定する。 この JENKINS_HOME には、バージョン管理システムからチェックアウトしてきたファイルなどが保存される。 デフォルトでは、実行ユーザのホームフォルダ以下に .jenkins というフォルダが作成され、そこが利用される。 デプロイ Tomcat の webapps フォルダにダウンロードした war ファイルを配置する。 動作確認 Tomcat を起動して http://localhost:8080/jenkins/ にアクセスする(ホストとポートは適宜読み替え)。 簡単なプロジ
フロントエンド front end バックエンド back end アプリ開発 app インフラ infra その他 other データドリブン data driven タグ一覧 Ajax(1) Android(20) Apache(2) AR(2) benchmark(1) BigQuery(2) browsersync(1) C4(1) CakePHP(1) CentOS7(1) CI(1) CMS(3) CoreNFC(1) CraftAR(1) CSS(1) DeepLab(2) Dmitry Stogov(1) ECMAScript(1) ECMAScript6(1) ElePHPant(1) Facebook(3) FFmpeg(1) firebase(1) fluentd(1) Framework(1) GD(2) gif(2) Git(1) GLSL(5) Google A
Jenkins からの移行のために今更だけど使ってみたメモ。 なお、うちの Gitlab はソースから入れていてデータベースも MySQL です。たまにしかバージョンアップしていないのでちょっと古いです(8.17.2)。 参考 https://docs.gitlab.com/ee/ci/ 公式のドキュメント https://docs.gitlab.com/ee/ci/yaml/README.html .gitlab-ci.yml のリファレンス https://docs.gitlab.com/ee/ci/runners/README.html Runner のドキュメント https://docs.gitlab.com/runner/ 公式の Runner の実装のドキュメント https://gitlab.com/gitlab-org/gitlab-ci-multi-runner ↑のリ
WindowsでビルドやテストをするようなCIがGitLab CIで簡単に構成できるので紹介します。 簡単にわかるGitLab CIの仕組みで書いたように GitLab RunnerはGitLab本体とは分離して別マシンや別コンテナに配置して、GitLabとGitLab Runner間はAPIで通信する仕組みになっています。 ということなので、ビルド環境のある物理WindowsマシンにGitLab Runnerを設置することでWindows版CI用Runnerを構築できます。 Install GitLab RunnerはGolangで書かれておりシングルバイナリとして配布されており、インストールはバイナリを配置するだけokです。 x86: https://gitlab-ci-multi-runner-downloads.s3.amazonaws.com/latest/binaries/gi
開発者はGitLabのプロジェクトにおいてmasterブランチにpushすることが可能な権限(Owner以上)を有していること 開発者はプロジェクトのリモートリポジトリとssh接続できること 開発者のマシン環境にGradleとOpen JDKが予めインストールされていること 「GitLab CI」を理解する 「GitLab CI」とは GitLab CIはCI(Continuous Integration、継続的インテグレーション)ツールの一つです。GitLab 7.14から8.0へのメジャー・アップデートにより、GitLab CIはバージョン管理機能を有したGitLab CE/EEに統合されました。 From 7.14 to 8.0 | GitLab.org / GitLab Community Edition · GitLab 「GitLab Runner」とは 「GitLabサーバー
継続的インテグレーション(CI:Continuous Integration)を行うため、CentOS6.5にJenkinsをインストールしてみました。 インストール JenkinsはJavaで動作しているため、Javaをインストールします。 $ yum -y install java-1.7.0-openjdk公式サイトにある手順を参考にJenkinsをインストールします。 $ wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo $ rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key $ yum -y install jenkinsJenkinsの自動起動の設定とサービスを起動します。 $ chk
jenkins の設定 Jenkinsのプロジェクトの設定で、ビルド・トリガ>リモートからビルド を選択し、ビルド用のトークンを設定する。 ここでは仮に"hogehoge"としたとする。 ためしにURLを叩いてみる これでビルドが実行されればOK ちなみに、トークンを使用するのは「セキュリティを有効」に設定している場合のみ。 まちがってユーザ設定しないまま、セキュリティを有効にして管理画面を閉じてしまうと何もできなくなってしまう(復帰方法はるのかな?)ので注意。 その場合、以下のページを参考に「セキュリティを有効にする」を無効化することができた。 git リポジトリのフックスクリプトに追加する ※サーバ側のリポジトリで設定する hook/post-update ファイルを用意
はじめに 「開発者(個人)のための」としているのは、別に自分でやっても良いんだけど Jenkins に任せられるなら任せたい、くらいのモチベーションを表現したつもりです。 環境 Ubuntu 14.04 LTS Jenkins 1.573 Bootstrap になって雰囲気が変わりましたね 初期設定 Jenkins 初期設定 Plugin のインストール Git Plugin 依存しているPluginも自動的にインストールされます。 Git Parameter Plugin は、ビルド時に Extended Choice Parameter plugin の Single Select ようなパラメータ形式で、リビジョンやタグを選択できるプラグインです。 Git 初期設定 Git Install Git がインストールされていないなら、apt や yum でインストールしておいて良いでしょ
gitでリボジトリへコミットすると、それをJenkinsが検出して、ビルドを実行する仕組みを入れてみた。 通知にするべきかポーリングにするべきか、それが問題だ。# 調べてみると、gitのCommitからJenkinsにビルドさせる方法は2つあるっぽい。 git commit時にJenkinsに通知する方法 Jenkinsがgitリボジトリを定期的にポーリングする方法 通知だと、gitのフック機能を利用して、簡単に実現できる。 ポーリングだと、Jenkins GIT Pluginを使って実現できる。 通知方法だと、branchごとにビルドを起動できないという弱点がある。 今回は、post-commitの方法を利用する。(というより、ポーリングは挫折した) 環境# Windows 7 64bit Cygwin wgetでJenkinsのジョブをキックする# Jenkinsトークンを利用して、リ
概要 以前 Jenkins入門の入門 でJenkinsの概要と導入について調べましたが 1歩進んでGitHubと連携してGitにPushした時に自動ビルドを走らせるまでをやってみます ユニットテスト(単体テスト)やビルドなどを自動で走らせたい時に良いかと思います ここから応用するとプルリクエストをマージさせた時に走らせたりなど色々なタイミングで自動ビルドを行うことができます 手順 GitHubの設定 ※ 以下全てJenkinsサーバでの作業 GitHubにSSHを行ってknown_hostsに追加を行う $ sudo su -s /bin/bash jenkins $ mkdir ~/.ssh;cd ~/.ssh // 自分のメールアドレス $ ssh-keygen -t rsa -C test@example.com // パスワードを聞かれるが空で登録する $ chmod 600 id
やりたい事 環境 秘密鍵/公開鍵の作成配置 クライアント(jenkins)側での作業 gitサーバー側での作業 Jenkins設定 jenkinsにgitプラグインをインストールする。 プロジェクト作成、設定 ビルドしてみる やりたい事 独自のjenkinsサーバーとgitサーバー(それぞれ別サーバー)を連携してビルド環境を構築する。 環境 CentOS 6.6 jenkins-2.25 git 2.10.0※事前にそれぞれのサーバーにgitがインストールされている必要あり 秘密鍵/公開鍵の作成配置 クライアント(jenkins)側での作業 ※jenkinsを起動しているユーザー(ここではroot)で実行 opensshがインストールされている事。 鍵ペア作成 ssh-keygen -t rsa複数ユーザーが利用する事を想定して鍵の名前を指定する。 Enter file in which
MULTI-STAGE-CI SYSTEM WITH JENKINS INTHE EMBEDDED WORLD RobertMartin JC-U, 25-06-2014 Multi-Stage-CISystemwith Jenkins,JC-U, 25.06.2014 Page2 AGENDA Some words about me Some questions toyou SW development environment for embedded devices Why Multi-Stage-CI ? Multi-Stage-CI Overview Nightly Build versus Continuous Integration Automatic Integration, Flashing and Testing in HW Some recommenda
これはFujitsu Advent Calendar 2016の21日目の記事です。 ※タイトルについて、申し訳ないですがハウツーではないです。 はじめに 先日、Cloud Foundry Days in Tokyoというコミュニティイベントに参加してきました。 資料はconnpassに公開されていますが、ConcourseというCI/CDツールが度々登場しました。 プロペラマークが目印です。 concourseはよいものですよ #cfdtokyo — Ken Ojiri (@kenojiri) 2016年11月11日 Cloud FoundryとConcourse CI使っています #cfdtokyo pic.twitter.com/IVR5xjcKcu — Toshiaki Maki (@making) 2016年11月11日 Circle of code #cfdtokyo pic.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く