blog.sugai.dev

はじめに 巷にはDangerというPull Requestのチェックを自動化するツールがありまして、自分のプロジェクトにも導入してみたいなと考え

単一のjobかworkflowsを使うかでやり方が異なります。 単一のjobの場合 branchesを使います。 masterブランチでのみ処理を

ステップが失敗しても次のステップを実行したい Circle CI 1.0とは異なり、2.0ではステップが失敗すると次のステップは実行されません。 ちなみにコマン

dockerのuserattributeを使います。 例: version: 2 jobs: build: docker: - image: circleci/ruby:2.5.0-node-browsers user: root steps: - run: command: whoami 結果: #!/bin/bash -eo pipefail whoami root 例のcircleci/rubyのデフォ

たとえば下記のような感じでCircleCIのビルド番号を参照して新たに環境変数をenvironmentセクションの中で定義しようとしても期待

workflowを利用して、build jobで作成した成果物をdeploy jobで特定の場所にリリースしたいことはよくあると思います。 Circle CI 2

CircleCI Tokyo User Meet-Upに行ってきたので、そこで見聞きしたことを簡単にお伝えしたいと思います。 Circle CIが2018年にリリースする大きめの機能3つ Protected

問題 GoogleのWebサイトパフォーマンス計測ツール、Lighthouseを定期的に実行したい。こんなときどうすれば良いだろうか？ 解決策 Circle

問題 ローカル環境でcircleciコマンドを実行するときに、環境変数を渡したいことがあると思う。こんなときどうすれば良いだろうか？ 解決策 circleci build

はじめに AWS LambdaでGolangが使えるようになったなあと思っていたら早速Serverless FrameworkでもGoが使えるようにな