compare-gradle-buildsプラグインについて
Gradle in ActionやGradle徹底入門で紹介されてて気になったので触って見てる。
checkstyleの設定ファイルが違った時にどのぐらいチェック結果が変わるのかを見れるかと思ったが、現在のバージョンだとZipアーカイブの比較しか出来ないっぽい。
64.2.2. Supported build outcomes Only support for comparing build outcomes that are zip archives is supported at this time. This includes jar, war and ear archives. Future versions will provide support for comparing outcomes such as test execution (i.e. which tests were executed, which tests failed, etc.)
今後に期待。
しかし、GradleないしGroovyは今後大丈夫だろうか。。。
Groovy 2.4 And Grails 3.0 To Be Last Major Releases Under Pivotal Sponsorship | Pivotal P.O.V.
ちなみに、compare-gradle-buildsプラグインでの比較時にデフォルトで実行されるのは
gradle clean assemble
だが、実行するタスクを変更するにはホストに下記のようなbuild.gradleを書けば良い。
apply plugin: 'compare-gradle-builds' compareGradleBuilds { sourceBuild { projectDir "Hoge" tasks = ["hoge","check"] } targetBuild { projectDir "Fuga" tasks = ["check"] } }
起動中のEC2インスタンスにリダイレクトするアプリ書
Node.js使ってEC2の起動中のインスタンスにリダイレクトするWebアプリ書いてみた。
Herokuに立てておけば、起動するたびに変わるPublic IPアドレスも気にならない。
使い方は上記GithubリポジトリのHerokuボタンからデプロイページへ行き、AWSのaccess_keyあたりを入力するだけ。
(Herokuのevn入力時にrequireの指定とかって出来るのかな)
AWS_FRONT_TAGSの所に key=value 形式でEC2インスタンスのタグを指定したフィルタリングできる。
もちろんAWSには静的IPをEC2インスタンスに割り当てるElastic IPあるので、普通はコッチを使う。
Elastic IP アドレス(EIP) - Amazon Elastic Compute Cloud
今回は書き辺りを目的として、自分で作ってみたりした。
- Heroku Buttonの素振り
- HerokuでNodeアプリを動かしてみる
- lodashを触ってみる
Heroku Buttonのデプロイページでenvをrequiredで無くする設定は普通にあった。
app.json env values required by default | Heroku Dev Center
node-webkit-builderを実行できない
備忘。
mllrsohn/node-webkit-builder をnpm installして実行しようとするとエラーとなる。
env: node\r: No such file or directory
これは既知の問題のようで、GithubのIssuesではvimのコマンドで解決する方法が紹介されていた。
env: node\r: No such file or directory
-
- -
ただ、viのコマンドをコマンドラインで実行できるか分からなかったので、.travis.ymlでは下記を参考に sed コマンドで改行コードを変換する処理を事前にやっておくことでとりあえず解決したようだ。
linux - How to convert DOS/Windows newline to Unix newline in bash script? - Stack Overflow
sed $'s/\r$//' # DOS to Unix
sed コマンドで元のファイルに上書き保存する方法は下記を参考に。
sedコマンドでファイルを上書き編集 | OpenGroove
-
-
- -
-
.travis.ymlのafter_successはこんな感じになった。
after_success: - npm install -g bower - npm install - sed -i -e $'s/\r$//' node_modules/node-webkit-builder/bin/nwbuild - "./build.sh"
Heroku Buttonを試すためにアンケートアプリを作ってみた
Githubに公開してあるソースをボタンひとつでHerokuにデプロイ出来る Heroku Button を試すために、アンケートアプリを作りました。
ので、作成過程の備忘録。
動作してるもの
enquete
Heroku Buttonの設置はREADMEにボタンを書いて、app.jsonを用意するだけなのでとてもお手軽。
app.jsonには使用するアドオンなんかも指定できるので、DB使ったアプリとかも問題なしですね。
Heroku Buttonはリファラを見てアクセス元のリポジトリからコードを取得しているようなので、Github上でブランチ生やして、そのブランチ上でHeroku Buttonをクリックすればブランチ上のコードからアプリをデプロイできる。
そこら辺上手く使えると便利そう。
アンケートアプリ自体は、ちゃんと作り込んだ訳ではないので怪しい部分は多々あり。
アンケート作成画面のライブプレビューがちゃんと動かなかったり。。。
Live Preview Error · Issue #18 · kaakaa/Enquete
中身の話
フレームワークはSinatra / Haml / ActiveRecord。
Markdown形式でアンケートが書けると良いなぁということで、StackOverflowのエディタであるwmdを使用しています。
(現在、wmdはpagedownとして公開されているようです pagedown - A JavaScript Markdown converter and editor - Google Project Hosting)
元々wmdにform要素を記述する機能は無かったようなのですが、Github上でformタグが記述できるように拡張したフォークが存在したのでそれを使用しています。
さらにSinatraから使えるように少し修正を加えました。
kaakaa/wmd
結果の集計画面は Highcharts による円グラフ等を使用しています。
Highchartsは手軽に使えるので良いですね。
備忘録
作ってる内に躓いた点を備忘として残しておきます。
- RubyのTimeで◯日後などを取得するにはActiveSupportが便利
- アンケートの回答を集計する
- mapとかinjectとか、まだまだ苦手だけど使えると便利そう
- Hamlからヘルパーメソッドを呼び、ヘルパー内でjavascriptコードを生成する
Gradleハンズオンをやりました
社内勉強会の一貫として、Gradleハンズオンを開催してみました。
Gradle入門の位置づけでやりましたが、時間配分がグダグダで最後の方は飛ばし飛ばしやってしまいました。
分かりづらかったなぁ…反省。
サンプルコード
共通のタスクをプロジェクト毎の設定値を利用して実行する
昨日の続き。
build.gradle
allprojects { configurations { svnant } ext { dep_repopath = new File("${project.rootDir}/../svn_repo/").canonicalPath dep_destpath = 'dep_project' depProjects = [] } dependencies { svnant fileTree(dir: "${project.rootDir}/lib_svnant", include: '**/*.jar') } task svnCheckout << { ant.taskdef(resource: 'org/tigris/subversion/svnant/svnantlib.xml', classpath: configurations.svnant.asPath) depProjects.each { def projectName -> def checkoutDest = "${project.rootDir}/${dep_destpath}/${projectName}" ant.svn(javahl: 'false', svnkit: 'true', failonerror: 'false') { ant.checkout(url: "file://${dep_repopath}/${projectName}", destpath: checkoutDest) ant.update(dir: checkoutDest) } } } } subprojects { apply plugin: 'java' repositories { mavenCentral() } dependencies { compile 'org.slf4j:slf4j-api:1.7.5' testCompile 'junit:junit:4.11' } } project(':App') { ext { depProjects = ["Stab"] } dependencies { compile project(':dep_project/Stab') } compileJava.dependsOn svnCheckout }
全プロジェクト共通のタスクsvnCheckoutでは、プロパティdepProjectsで指定されたプロジェクトをチェックアウトしてくる。
共通部分では
ext { dep_repopath = new File("${project.rootDir}/../svn_repo/").canonicalPath dep_destpath = 'dep_project' depProjects = [] }
のようにdepProjectsを空リストとして宣言しておき、Appプロジェクトの設定の方で
project(':App') { ext { depProjects = ["Stab"] } dependencies { compile project(':dep_project/Stab') } compileJava.dependsOn svnCheckout }
depProjectsに設定値を与えてあげると、共通のタスクをプロジェクト固有の設定値で実行することが出来る。
依存プロジェクトをsvnからチェックアウトしてからビルドを
昨日の続き。
Gradleのマルチプロジェクトビルドで、依存プロジェクトをSVNからチェックアウトしてからビルドを実行するサンプル。
kaakaa/GradleMultiprojectSample
とりあえず動いてはいるけど、SVN checkoutが汎用的に作れていない。
Gradleのタスクに引数を与えられれば、各プロジェクト毎に依存しているプロジェクト名を宣言して、SVN checkoutのタスクに渡して処理もできるんだけど…。
ん〜微妙。
GradleからSVNコマンドを実行する
SvnAntを使用した。
Gradle svn-ant Sample