CircleCI 2.0にSSH buildが登場したよ - Qiitaそのままの内容です 皆さんお待ちかねだった SSH build がCircleCI 2.0でも使えるようになりました 使い方は1.0の頃同様 rebuild with SSH を選択すれば良いです それでは皆さん良い開発生活を!!! ちなみに詳細は公式の Discuss CircleCI を参照のこと CircleCI 2.0 now supports Rebuild with SSH
CircleCI で Java8 プロジェクトのビルドを通す - Qiita
[INFO] Compiling 5 source files to /home/ubuntu/winchester/target/classes [INFO] ------------------------------------------------------------- [ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] Failure executing javac, but could not parse the error: javac: invalid target release: 1.8 Usage: javac <options> <source files> use -help for a list of
bitbucketの静的Webページをwerckerで自動CI/CDしてGithub Pagesにデプロイする - Qiita
背景 ソースコード管理システムとして2大巨頭のgithubとbitbucketですが、前者はパブリック、後者はプライベートリポジトリとして有用ですね。（githubのプライベート利用は有料） 今回はタイトルのままですが、OSS開発で活躍しているデプロイ自動化の技術を、個人開発だったり、企業資産としてコードは外に出したくない場合でも利用できるwerckerを使用してみました。 書店で参考資料を探してもまだ無かったり、Web上だと下位バージョンの情報があふれており各バージョンごとの情報が入り乱れていてなかなか手を出せなかったりするのではと思い書いてみようと思いました。 準備 各サービスのアカウント bitbucketアカウント（https://bitbucket.org/） githubアカウント（https://github.com/） werckerアカウント（http://www.wer
GitHub上のiOSプロジェクトでもTravis CI × CodecovでCIしたい! - Qiita
2017/01/31 追記 CodecovでUIテストのカバレッジがきちんと収集されてないな… と思い調査してみたところ，他のリポジトリでも同様の現象が起こっていたようです． どうやら，XcodeのIDEでUIテストを起動したときと，xcodebuildでCLIでテストを起動したときでは挙動が異なるらしく，それに起因するもののようです． 以下，参照したIssuesです． UITesting not reported - codecov/example-swift Always 0% - nakiostudio/xcov UI Testsのカバレッジ収集以外に関しては，UI Testsの起動含めきちんと想定通りの動作をしております． 2017/06/24 追記 Xcode9においてはこの問題は解決したっぽいです．なので，Xcode9をTravis側がサポートしてくれるようになるとUIテストの
Travis CI にまつわる Docker 関連のメモ - Qiita
Travis CI を触っている中で扱うことになる、 Docker に関わる設定についていくつかメモ的に書きます。 .travis.yml に sudo : false と設定すると docker container ベースで起動する これは 2015 年くらいから各所でよく言われている travis tips だと思います。 以下の公式マニュアルにあるように、2015 年以降から .travis.yml に sudo : false と設定すると docker container の上で CI が動作するようになります。これにより、CI が動作するまでのオーバーヘッドが短縮され、かわりに CI 中に sudo コマンドが使用できなくなります。 現在は、sudo オプションを明示的に指定しない場合は、デフォルトでは sudo : false 扱いになるようです。 https://docs.
Ansibleの2017年を眺めておこう - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに これまでにこんな記事を書いていました。 Ansible 2.0リリース！ Ansible 2.0がリリースされたときに書いたもの Ansible 2.0リリース記事の日本語訳 Ansibleのこれまでとこれから Ansible 2.1がリリースされたときに書いたもの これまでの振り返りとロードマップの解説 と、よくよく考えてみたらAnsible 2.2がリリースされたのになんの記事も書いていないことに気づきました。これはまずい。 というわけで(Advent Calendarの穴埋めをかねて)この記事を書き始めました。 Ansi
KubernetesにデプロイするDockerコンテナのログ形式を選ぶ - Qiita
TL;DR; プログラム的にparseやすい、構造化されたログメッセージを採用するとよいです。 また、構造化されたログメッセージにするためには、 ndjson形式(俗称? jsonlog) bunyan形式 logfmt形式 のいずれかをおすすめします。 なぜ構造化されたログメッセージがよいか? アプリケーションによって、デバッグや稼働確認、障害調査等の目的でログに含めたいデータは異なります。 アプリケーションの部分部分を担当したエンジニアによって、ログに含まれるデータのフォーマットが異なると、それが利用しづらい状態になってしまいます。 また、 KubernetesのCluster-Level Loggingにはfluentdが使われるということと、 アプリケーションが後の分析のためにログメッセージに付与しておきたいメタデータと、アプリケーションが動作している環境との関連付けのためにKub
Kubernetes: Deployment の仕組み - Qiita
この記事は Kubernetes 1.5.2 で確認した情報を元に記載しています。 Deployment Deploymentはローリングアップデートやロールバックといったデプロイ管理の仕組みを提供するものです。 Deployment の仕組み 下記の図のようにDeploymentはReplicaSetを生成・管理し、ReplicaSetはPodを生成・管理します。 ReplicaSet(ReplicationControllerの後継)はPodTemplateと呼ばれるPodのテンプレートをもとに、Podを指定された数(レプリカ数)に調整・管理を行う仕組みです。Podがレプリカ数より足りない場合はPodを追加し、多い場合はをPodを削除します。この仕組みによってノードの障害やアプリケーションのクラッシュでPodが足りなくなった際も自動的にPodが追加され、セルフヒーリングが実現されていま
Circle CIでテストにかかる時間を短縮 w/ Jenkins - Qiita
さいきん、Jenkinsのテストが遅い... specの肥大化... Jenkinsのインスタンスがm1.small… などなどは持続可能なCIを目指す上で大きな障壁であります。 じゃ、インスタンスでかくすりゃいいじゃん という事ができる方、分散rspecやってるぜheheな方はそれで幸せになれると思います。 え、あんまりお金ないし みたいな仲間は、@camelmasa 先生の記事読むと幸せになります。 プライベートリポジトリを激安にCI出来るCircle CIが凄い。 少し前から、Qiitaの皆さんにオススメしていただいたので検討してはいたのですが、ここまで良いとは思わなかった。 めっさ軽いし、安い Dashboardからして軽い。 日本に置いているのか先読みしているのか分からないけど、軽い。 １つのプライベートプロジェクトなら$19/moという破格。 実際、早くなったよ ちゃんと計測し
Circle CIでテストにかかる時間を短縮 w/ Jenkins - Qiita
さいきん、Jenkinsのテストが遅い... specの肥大化... Jenkinsのインスタンスがm1.small… などなどは持続可能なCIを目指す上で大きな障壁であります。 じゃ、インスタンスでかくすりゃいいじゃん という事ができる方、分散rspecやってるぜheheな方はそれで幸せになれると思います。 え、あんまりお金ないし みたいな仲間は、@camelmasa 先生の記事読むと幸せになります。 プライベートリポジトリを激安にCI出来るCircle CIが凄い。 少し前から、Qiitaの皆さんにオススメしていただいたので検討してはいたのですが、ここまで良いとは思わなかった。 めっさ軽いし、安い Dashboardからして軽い。 日本に置いているのか先読みしているのか分からないけど、軽い。 １つのプライベートプロジェクトなら$19/moという破格。 実際、早くなったよ ちゃんと計測し
Circle CIで一定量のカバレッジに行かなかったらテストを落とす。 - Qiita
CircleCIで一定量のcoverageに達しない場合はテストを落として、デプロイしない用にする。 前提 railsで開発を行っている。 gem simplecovを導入している。 rspecを導入している(他のテストツールでも多分大丈夫) CircleCI自体はそのような機能は持っていない。下記問い合わせの返信内容。 We don't have anything built-in to prevent deploys when the test coverage is low. However, it looks like you're using simlecov. You can configure simplecov to fail the tests if the coverage is not high enough: https://github.com/colszowka
Circle CIでparallel実行したsimplecov結果の収集 - Qiita
TravisCIにせよCircle CIにせよ通常その結果を得るには「取れるところにおいて取ってくればいい、終了！」なんだけど、人類には早すぎる並列実行テクノロジーをやむを得ず使わざるを得ない場合には人智を越えるので大変なわけです。 その具体例として(?)今回はCircle CIでparallel実行したsimplecovの結果収集を取り上げます。 対象のソースコードの取得 後述しますが、まず対象のソースコードが必要です。GitHubからの場合、https://github.com/<username>/<reponame>/archive/<commit>.tar.gz を取ってきて、tar -C /tmp -xf repo.tar.gzするのが楽でしょう。Private Repositoryの場合はOauth tokenを取得してBasic Authに<username>:<token
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CircleCIでLintとTestをParallel実行 - Qiita
Circle CI でgh-pages自動ビルドして自動デプロイ - Qiita
Githubのprivateリポジトリで管理しているElectronアプリをCircleCIとGitlabCI使ってビルドする - Qiita
CircleCI 2.0 では Docker ビルドキャッシュが効く - Qiita
CircleCIのテストでRedisを使う - Qiita
CircleCIで静的サイトのS3向け自動デプロイ - Qiita
Circle CIをカスタマイズしてテストからデプロイまで - Qiita
Circle CIを使ったNode.jsプロジェクトのテスト - Qiita
