Help us understand the problem. What is going on with this article?
概要 ある開発中プロジェクトで、これまで JS のテストカバレッジを活用出来ていなかったため軽い気持ちでやっていきをしたら、 開発環境では設定した閾値を越えるのに CI 上ではパスしないためデプロイできないという状況が起こりました。 環境 開発マシン OS: maxOS 10.12.6 Node.js: 10.8.0 npm: 6.3.0 CI (Wercker) OS: Debian stretch-slim Node.js: 8.x npm: 6.x どちらも Jest のバージョンは 23.4.1 を利用しており、 設定も package.json に記述しているため共通のものを利用しています。 また、カバレッジに関する設定は閾値の設定しか行っていません。 Jest 実行時のコマンドは以下。
背景 dep を使った Golang のビルドで同じ wercker.yml を使っているのに Wercker CLI の Local Mode では wercker build が通るのに、Wercker の Web 側では通らなかった。 調査 エラーログ go build の段階で失敗し、そのログは go build main.go:x:x: cannot find package "github.com/pkg/errors" in any of: /usr/local/go/src/github.com/pkg/errors (from $GOROOT) /go/src/github.com/pkg/errors (from $GOPATH) make: *** [build] Error 1 と、パッケージが GOROOT および GOPATH で見つからないとのこと。 dep
![[未解決]Wercker で dep を使った Golang のビルドが Wercker CLI の Local Mode では動くが、Wercker では動かない問題 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/418d64bb7b82f8d27f56a8b304e06e625324ac63/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%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-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCJUU2JTlDJUFBJUU4JUE3JUEzJUU2JUIxJUJBJTVEV2VyY2tlciUyMCVFMyU4MSVBNyUyMGRlcCUyMCVFMyU4MiU5MiVFNCVCRCVCRiVFMyU4MSVBMyVFMyU4MSU5RiUyMEdvbGFuZyUyMCVFMyU4MSVBRSVFMyU4MyU5MyVFMyU4MyVBQiVFMyU4MyU4OSVFMyU4MSU4QyUyMFdlcmNrZXIlMjBDTEklMjAlRTMlODElQUUlMjBMb2NhbCUyME1vZGUlMjAlRTMlODElQTclRTMlODElQUYlRTUlOEIlOTUlRTMlODElOEYlRTMlODElOEMlRTMlODAlODFXZXJja2VyJTIwJUUzJTgxJUE3JUUzJTgxJUFGJUUyJTgwJUE2JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1kNTRlYTFkNWQ1M2NmZmUzM2Y2ZWJhZGEyZTk1NzVkYw%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwbm9pc3NlZm5vYyZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9NWRlZWM1YTg2ZDQ2ZjNkZTFhNWI5ZTcwYmE1ZTFhODQ%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D19e7413a821a9f3697b4aa2e18951fed)
build: steps: # プロジェクトルートを GOPATH 配下に移動 - wercker/setup-go-workspace: package-dir: <SOME_PATH> # glide をインストールして glide install する - glide-install # ビルド - script: name: compile binary code: | go build # テスト - script: name: test code: | go test 上記でローカル/Web共にCIが通るようになった。 課題 Wercker で Go の CI を実行できるようになった。しかし、 dep への対応はできていない。 glide 自身が dep への移行を促しているので、 dep に対応したい。 wercker/step-glide-install を参考にして s
GitHubで利用できるCIのひとつ、Werckerの基礎知識についてまとめる 1.Werckerとは 2012年にオランダで誕生したCI-as-a-Service。リポジトリへのソースコミットをトリガーとしてアプリケーションのビルド、テスト、デプロイを自動化できるサービス。読み方は「ワーカー」。 github、bitbucketで利用することができる。 2.特徴 Werckerは、リポジトリのルートに「wercker.yml」を準備し、その中にテストの実行環境やデプロイコマンドをあらかじめ記載しておくことによりソースがコミットされたタイミングで自動的に記述された処理を行ってくれる。 Werckerでは、その実行環境を"box"、コマンド群を"step"として自作することができ、それを「Wercker Directory」に登録しておくことで様々なテストから実行環境やコマンド群を呼び出すこ
wercker導入手順① 前回はwerckerの登録とアプリケーションの作成まで行いましたので、今回はymlというwerckerの設 定ファイルの作成から配備までを行います。 ここまでで一旦最低限の導入は完了となります。 ymlって？ YAMLという表現記法の拡張子です。YAMLとは何か？というと構造化したデータを記述するための表現記法で、Rubyやフレームワーク、ツールの設定ファイルなどでよく使います。 詳しくはこちらの記事で分かりやすくまとめられています。 WerckerではこのYAMLを使ってビルドやデプロイの手順を記載していきます。 wercker.ymlの設定 作成したアプリケーションを選択し、「runs」タブから使用言語を選択。 （ここではrubyを選択） ymlの内容をコピーし、ファイル名を"wercker.yml"として保存する。 box: ruby:2.4.2 servi
基礎概念 step pipeline（build deploy devなどのこと） workflow（pipelineをさらに組み合わせたもの） service（PostgresやElasticSearchなどを使いたい場合は、それらをserviceとして指定する） application user organization デフォルトではapplicationはpublicになっているので注意。 werckerの仕組み werckerはDockerベースである boxで指定したDockerコンテナ内で実行される boxにはDocker Hubに登録されているDockerイメージをなんでも指定できる PostgresやElasticSearchなどを使うにはserviceを使う serviceは別のDockerコンテナとして実行され、Docker Linkによってリンクされる あるコンテナ
はじめに Serverless Frameworkを利用してAWS Lambdaの関数をpythonで開発しています。 機能実装するたびにデプロイするのが面倒だったので、CIサービスであるWerckerを使って自動化したときのメモとなります。 AWS LambdaのFunctionデプロイ 何も考えずにデプロイしようとすると、ローカル環境で開発したコード群をzipファイルにアーカイブしてAWSのコンソールからアップロードする感じになります。 デプロイ以外にもテスト実行など色々と面倒なので、多くの人がServerless Frameworkを利用していると思います。 Serverless Frameworkを利用したデプロイ Serverless Frameworkはサーバレス環境でのAPIやFunctionの開発をいいかんじにサポートしてくれるライブラリです。 デプロイも以下のようなコマン
Google App Engineってサーバレスで大体のものは作れるので、とっても便利な感じです。 ただ、デプロイしようとすると、どこかのマシンなりサーバでdeployコマンドを叩かないといけません。 特定の開発者のマシンに依存すると、デプロイの回数が多くなると負担になりますし、マシンがクラッシュするとデプロイできなくなる……という難点が。 とはいえ、デプロイ用のサーバをわざわざ用意すると今度は24/365で費用がかかるというデメリットが。 という訳で、werckerを使ってみようと思います。 staging環境は指定のブランチにpushされる度に自動デプロイ、本番には任意のタイミングで手動でデプロイできるようにしてみようと思います。 ※使用したソース https://github.com/fumihiko-hidaka/gae-deploy-test 簡単な仕組みの図 デプロイ設定ファイ
TL;DR Githubにgit pushすると自動CIがテストしてくれるようにしたら最高でつよいエンジニアの人たちが「自動CI/CDは当たり前」と言ってる意味を完璧に理解した。 Oracle + Wercker 現在は自動CDまでは行っていなくてgit push→CI(Wercker)→Slack通知という流れになっている。 Wercker導入以前は誰かが書いたコードの一部がテストを通ってなかったり、rubocopが怒るようなコードの書かれ方をしていてその状態でマージされてしまって他人のコードに影響がでるということが起こっていた。 pushする前に手元でテストしろ！とかrubocop動かせ！問題あれば自動フォーマットしろ！とかレビューできちんと問題のあるコードを指摘しろ！というのはある。 だがしかし、人間はだいたい自分にとって都合よく忘れたり、「これくらいならいいだろ」と思ってミスを起こ
Rails アプリケーションのE2Eテストを書きました。 構成は Capybara + Selenium + Headless Chrome です。 このE2Eテストを Wercker で実行するために、 下記のスクリプトで Wercker に Chrome をインストールしました。 - script: name: install chrome headless code: | apt-get update -y wget -q -O - https://dl.google.com/linux/linux_signing_key.pub | apt-key add - echo "deb http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google-chrome.list apt-
Werckerで「Mysql2::Error: Authentication plugin 'caching_sha2_password' cannot be loaded」が発生した際の対処についてMySQLwercker Werclerのプロセスが失敗 連休明けのとある日、いつものようにgit pushすると、CIに使っているWerckerからエラー通知が届いた。 内容を見てみるとspecにたどり着く以前の、テスト用DBを作成するステップでエラーになっていた。 エラーメッセージは「Mysql2::Error: Authentication plugin 'caching_sha2_password' cannot be loaded」。 Mysql2::Error: Authentication plugin 'caching_sha2_password' cannot be load
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
