Heroku :: Wercker Documentation
Heroku This article explains how to deploy an application with Wercker to Heroku. For this tutorial you need both a Heroku account and an account on Wercker. The application developed in this tutorial is a simple Node.js web application, but most of the patterns apply to other programming languages as well. Requirements A Heroku account An account on Wercker The Wercker command line interface, whi
wercker使うのをあきらめた（けど、頑張ったらできた） - depository
CIでGitHub pagesの更新をしようと思った このサイトの更新をGitHubにsourceブランチからpushしただけでできるようにしようと思って、werckerでやろうと画策したんだけどどうやっても動かない。試したのは次のような感じ。 Personal access tokenを使っての方法 Personal access tokenを使えばGitHubへのアクセスがかなり制限できるし、いざとなったらトークンを消せばいいだけなので、まずはそれでやろうと思い立った。 Personal access tokenをwerckerみたいに毎回初期化される環境でやるには、.netrcに次のように書いておけばいいと思ってやってみた。 machine github.com login ymotongpoo password xxxxx しかしどうもwerckerはpushの際にはSSHプロトコ
Mac と Debian stretch とで Jest の coverage 結果が違った話 - Qiita
概要 ある開発中プロジェクトで、これまで 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 実行時のコマンドは以下。 閾値を設定したままデプロイ出来るようになりました。 開発環境、CI環境のカバレッジが一致する
[未解決]Wercker で dep を使った Golang のビルドが Wercker CLI の Local Mode では動くが、Wercker では動かない問題 - Qiita
背景 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%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)
Wercker で glide を使った Golang のビルド - Qiita
はじめに Wercker で dep を使った Golang のビルド でうまくいっていなかった。そこでアプリを先に書くことにした。が、アプリが書きあがってしまったので dep への移行が促されているが Masterminds/glide を使うことにした。 tl;dr wercker.yml の build の steps に glide-install を書く。 全体的には以下 build: steps: # プロジェクトルートを GOPATH 配下に移動 - wercker/setup-go-workspace: package-dir: <SOME_PATH> # glide をインストールして glide install する - glide-install # ビルド - script: name: compile binary code: | go build # テスト -
Wercker基礎知識 - Qiita
GitHubで利用できるCIのひとつ、Werckerの基礎知識についてまとめる 1.Werckerとは 2012年にオランダで誕生したCI-as-a-Service。リポジトリへのソースコミットをトリガーとしてアプリケーションのビルド、テスト、デプロイを自動化できるサービス。読み方は「ワーカー」。 github、bitbucketで利用することができる。 2.特徴 Werckerは、リポジトリのルートに「wercker.yml」を準備し、その中にテストの実行環境やデプロイコマンドをあらかじめ記載しておくことによりソースがコミットされたタイミングで自動的に記述された処理を行ってくれる。 Werckerでは、その実行環境を"box"、コマンド群を"step"として自作することができ、それを「Wercker Directory」に登録しておくことで様々なテストから実行環境やコマンド群を呼び出すこ
wercker導入手順② - Qiita
wercker導入手順① 前回はwerckerの登録とアプリケーションの作成まで行いましたので、今回はymlというwerckerの設 定ファイルの作成から配備までを行います。 ここまでで一旦最低限の導入は完了となります。 ymlって？ YAMLという表現記法の拡張子です。YAMLとは何か？というと構造化したデータを記述するための表現記法で、Rubyやフレームワーク、ツールの設定ファイルなどでよく使います。 詳しくはこちらの記事で分かりやすくまとめられています。 WerckerではこのYAMLを使ってビルドやデプロイの手順を記載していきます。 wercker.ymlの設定 作成したアプリケーションを選択し、「runs」タブから使用言語を選択。 （ここではrubyを選択） ymlの内容をコピーし、ファイル名を"wercker.yml"として保存する。 box: ruby:2.4.2 servi
wercker APIの使い方 - Qiita
現在のところ、提供されているendpointは4つ。今後拡充していくとのこと。 applications runs builds（古いstackのユーザー向け。新しいユーザーはrunsを使うこと） deploys（古いstackのユーザー向け。新しいユーザーはrunsを使うこと） トークンの取得方法 画面右上の自分のアバター→Settings→Personal tokens からトークンを発行できる。トークン発行後は見えなくなるのでメモしておくこと。 application一覧 ※$WERCKER_USERNAMEはログインするときの名前 curl -H "Authorization: Bearer $TOKEN" https://app.wercker.com/api/v3/applications/$WERCKER_USERNAME
werckerで途中の状態をDocker Hubにpushする - Qiita
TLDR werckerのパイプラインはDockerコンテナ内で実行される。wercker.ymlにinternal/docker-pushというステップを組み込むと、その時点のコンテナの状態をDockerイメージ化し、Docker Hubにpushすることができる。これを使うとパイプラインがうまく動かないとき問題調査に役立つかもしれない（実際に調査に使ったことはまだないので）。 wercker.ymlにinternal/docker-pushを追加 steps: # （中略） - internal/docker-push: username: $DOCKERHUB_USERNAME password: $DOCKERHUB_PASSWORD repository: myname/repo_name $DOCKERHUB_USERNAME, $DOCKERHUB_PASSWORD は環境変
werckerの基礎知識 - Qiita
基礎概念 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 をつかったデプロイをwerckerで自動化する - Qiita
はじめに Serverless Frameworkを利用してAWS Lambdaの関数をpythonで開発しています。 機能実装するたびにデプロイするのが面倒だったので、CIサービスであるWerckerを使って自動化したときのメモとなります。 AWS LambdaのFunctionデプロイ 何も考えずにデプロイしようとすると、ローカル環境で開発したコード群をzipファイルにアーカイブしてAWSのコンソールからアップロードする感じになります。 デプロイ以外にもテスト実行など色々と面倒なので、多くの人がServerless Frameworkを利用していると思います。 Serverless Frameworkを利用したデプロイ Serverless Frameworkはサーバレス環境でのAPIやFunctionの開発をいいかんじにサポートしてくれるライブラリです。 デプロイも以下のようなコマン
Google App Engineへのデプロイをgithub -> werckerで自動化する（手動でもできるようにする） - Qiita
Google App Engineへのデプロイをgithub -> werckerで自動化する（手動でもできるようにする）GitHubGAEwerckerGoogleCloud Google App Engineってサーバレスで大体のものは作れるので、とっても便利な感じです。 ただ、デプロイしようとすると、どこかのマシンなりサーバでdeployコマンドを叩かないといけません。 特定の開発者のマシンに依存すると、デプロイの回数が多くなると負担になりますし、マシンがクラッシュするとデプロイできなくなる……という難点が。 とはいえ、デプロイ用のサーバをわざわざ用意すると今度は24/365で費用がかかるというデメリットが。 という訳で、werckerを使ってみようと思います。 staging環境は指定のブランチにpushされる度に自動デプロイ、本番には任意のタイミングで手動でデプロイできるようにし
Oracle WerckerでGithubにpushされたら自動でCIが動くようにした - Qiita
TL;DR Githubにgit pushすると自動CIがテストしてくれるようにしたら最高でつよいエンジニアの人たちが「自動CI/CDは当たり前」と言ってる意味を完璧に理解した。 Oracle + Wercker 現在は自動CDまでは行っていなくてgit push→CI(Wercker)→Slack通知という流れになっている。 Wercker導入以前は誰かが書いたコードの一部がテストを通ってなかったり、rubocopが怒るようなコードの書かれ方をしていてその状態でマージされてしまって他人のコードに影響がでるということが起こっていた。 pushする前に手元でテストしろ！とかrubocop動かせ！問題あれば自動フォーマットしろ！とかレビューできちんと問題のあるコードを指摘しろ！というのはある。 だがしかし、人間はだいたい自分にとって都合よく忘れたり、「これくらいならいいだろ」と思ってミスを起こ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Werckerの環境変数やwercker.ymlで$(ドルマーク)を使う - Qiita
Java+GradleのアプリケーションをWerckerでビルドとテストする - Qiita
Java+Gradle+Wercker構成でCodecovによるカバレッジチェックする - Qiita
https://cloud.oracle.com/containers/pipelines
wercker + RailsでPostGISを使う - Qiita
wercker CLIを使ってwercker.ymlをローカルで実行する - Qiita
GithubのPRにWerckerのBotが出なくなった件 - Qiita
