werckerに関する情報が集まっています。現在154件の記事があります。また103人のユーザーがwerckerタグをフォローしています。

漢なら GitHub コミットして Travis ビルドして Bintray へデプロイですね! travisCI + Bintrayによる自動デプロイを試したメモ 参考になります, ありがとうございます. しかし Travis が用意しているサンプル手順 https://docs.travis-ci.com/user/deployment/bintray/ だと, バージョン番号は手動で JSON に書く必要があります. 毎回手作業はめんどうですね... 人間の欲望は飽きない. git tag を打ったら自動でよろしく tag 名でバージョンを設定してよろしく Bintray にアップロードしたくなりますね. そこで sed でバージョン番号とリリース日を travis ビルド後に書き換えた .json を作り bintray にアップロードする手を考えてみました. tinyobjloa
注意 この記事で紹介しているテクニックを用いて作成した文書を、配布したり販売したりしてよいかについては現在調査中であるので、この記事の内容はあくまでも「そういうこともできる」程度に考えて欲しい。また、もしTravis CIで作成した成果物のライセンスなどに関する情報をお持ちの方がいらっしゃいましたら、この記事のコメントなどで知らせて欲しいと思う。 2016/6/25 AppleのLegal Questionに問い合わせメールを送ったものの、返答がありません……。 はじめに 本や冊子などをLaTeXで作成する際には、フォントにこだわりたくなることがある。有名なフォントとしてヒラギノフォントがあるが、ヒラギノフォントは有償なので、フォントを購入するかあるいはMacを買う必要がある。この記事では、Travis CIを使ってお金を支払うことなくヒラギノフォントが埋め込まれたPDFをLaTeXで生成
この記事はAndroidのCI環境をCircleCIからWerckerにした話に関連した投稿です。 AndroidアプリのCI/CDをどう行うのかを考えるとkeystoreやkey.p12などのファイルを何処に置くか?が問題になることがあります。Androidプロジェクトのリポジトリに含めてしまう事もできますが、セキュリティの観点からできるだけ避けたいです。 今回試してみたのは、keystoreなどのファイルをIP制限をかけたs3のバケットに置き、それをWerckerから取得する方法です。 keystoreをs3から取得し./gradlew assembleReleaseを実行するwercker.ymlを作成してAndroidプロジェクトのビルドを実行してみます。 s3のバケットにIP制限をかける IP制限のかけかたはこちらの記事が参考になります。実際にAWS Policy Generat
この記事はWHITEPLUS Advent Calendar 2016 5日目になります。 株式会社ホワイトプラス、エンジニアの @akaimo です。 ホワイトプラスでは主にリネットのiOSアプリを担当しています。 iOSアプリのリリースや配布は手間がかかる iOSアプリをリリースしたり、開発版を配布しようと思うと、各開発者のMacに証明書をインストールしなければいけません。 しかし、Appleの証明書は複雑なため、なかなかスムーズにいきません。 また、アップロードできる人を絞ってしまうと、負荷の集中、不在時にどうするかなどの問題も発生します。 そこでホワイトプラスでは、Travis CIを利用してリリース・配布のフローを自動化しています。 CI環境を作ってしまえば、つい忘れていつの間にかテストが通らなくなっている、なんてことも防げ品質を高く保つこともできます。 利用するサービス Git
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちは皆さん CIっていい響きですよね! 継続的インテグレーション、なんて日本語に訳すとなんのことだかわからないところもおしゃれです。 現在ポピュラーなCIサービスといえば、github連携のTravis CIじゃないかと思います。 ここは自分もおしゃれ開発の仲間入りしたい!とばかりに、Travis CIを使ってみたのですが、昔普通にphp環境で組んだことがあったので、今回はdockerを使ってしまおうと思い至ったのです。 ...まあ、オシャレで優雅に見える開発も、水面下で泥臭い検証実験を繰り返しているものです。 そんなわけで、Tr
前置き Wercker は Docker コンテナの中で CI をするサービスで、とりあえずビルドに必要な環境が整った Docker イメージがあれば、あとは Wercker が勝手にイメージを引っ張ってきてコンテナを立ち上げて指示通りビルドをしてくれるため、公式ドキュメントにはない Android アプリのビルドも可能です。 ビルドに必要な環境はすべて Docker イメージにまとめて放り込んでしまえるので、SDK の更新があったときに CI サービス側の対応を待たなくとも、自分でイメージを作り直すだけで環境を最新に保つことができる点が魅力ですが、裏を返せば自分で環境をメンテナンスしなくてはならないという面倒臭さがあります。 とは言え、CI サービス側が環境を用意してくれる場合でも、自分で環境をメンテナンスする場合でも、環境が新しくなってもビルドが壊れないことの確認は最低限する必要がある
Dockerコンテナを動かす時のメモリ制限 Dockerにはコンテナが使えるメモリの上限を設定するオプションがあります。 ただし、Werckerがコンテナで使用可能なメモリの制限をしていることはないようです。 @KeithYokoma currently, there is no limit for internal memory. If you're asking about storage, I'll need to get back to you! — wercker (@wercker) 2016年4月14日 とはいえ際限なく無限にメモリが使えるかといえばそんなことはないはずなので、物理的にどの程度まで余裕があるのか見たくなりました。 cat /proc/meminfo MemTotal: 65965708 kB MemFree: 19718212 kB MemAvailable:
この記事はWHITEPLUS Advent Calendar 2016 23日目になります。 株式会社ホワイトプラス、エンジニアの @akaimo です。 ホワイトプラスでは主にリネットのiOSアプリを担当しています。 はじめに WHITEPLUS Advent Calendarの中で以下の記事のように、iOS開発用のTravis CIを構築してきました。 Travis CIでつくるiOSのCI環境(準備編) Travis CIでつくるiOSのCI環境(テスト・アップロード編) 今回は最後の仕上げとして、運用する上でのコツを書いていきたいと思います。 実行時間の短縮 Travis CIの環境を構築したら、一番始めに課題となって立ちふさがるのは、実行時間の問題だと思います。 時間がかかるポイントとしては、 環境構築(ビルドまでの準備) ビルド アーカイブ アップロード があります。 アップロ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く