Docker+DjangoをCircleCiでHerokuに継続デプロイする - Qiita
.circleci/ config.yml setup_heroku.sh application/ application/ manage.py docker-compose.yml Dockerfile requirements.txt すぐに試す フォークなどで自分のリポジトリにクローンします。 herokuでアプリ・Token作成 heroku login Herokuにログインします heroku create アプリ名でアプリを作成します heroku authorizations:create -d "getting started token"でトークンを作成します トークンはあとで使うのでコピー CicleCIでGitHubリポジトリからプロジェクトを作成 CircleCIの環境変数(Environment Variables)にHerokuの認証情報を登録 リポジトリを
Nuxt.js でポートフォリオサイトを作成した記録 - Qiita
端書 これは Nuxt.js を使ってポートフォリオサイトを作ったのを GitHub の履歴を見返しながらメモ的に書き起こしたものです。 割と詳細を忘れていてきちんと作業日誌付けておけばよかったと後悔…。とはいえ詰まった部分をかなり思い出したのでこれを読んだ方が同じ轍を踏まない＆アドバイスをいただければ幸いです。 ちなみにスキルは React/Redux と Vue.js で経験あり。Nuxt.js や Firebase は初めてという具合です。 モチベーション 一介の Web エンジニアとしてこの度は転職活動を始めようと思い立ったのですが、自分の場合はプライベートの開発物が全く無かったのです。Qiita などの細々とあるアウトプットや職務経歴書だけではアピールが足りません。というわけで手っ取り早くアピールできる制作物としてまずはポートフォリオサイトを作ることにしました。 最終的な成果物
CircleCIでカスタムDockerイメージを使う - Qiita
参考 https://circleci.com/docs/2.0/custom-images/ やりかた Dockerfileを作る ビルドしてDockerHubにアップロード 「.circleci/config.yml」にイメージを設定 実際にやってみる 1. Dockerfileを作る どんな言語でも良いですが、とりあえずGoでやってみます。 今回は「AWSで運用しているアプリで、CircleCI経由で自動デプロイをする」という 体のアプリを想定して書いてみました。 FROM golang:1.9 ADD . /go/src/github.com/your-repository WORKDIR /go/src/github.com/your-repository ENV DEBIAN_FRONTEND noninteractive # depを使っている場合 RUN go get -u
CircleCI2.0上でDangerを使ってみる - Qiita
※ 12/19 以前、githubのアクセストークンの設定のところを自分のアカウントと書いてて、リンクしていただいた@chamaoさんの記事を見て、 「あっ」って、なったので文章を一部修正、スクリーンショットの追加をしました。 導入した理由 プロジェクトによって「この作業やった時は、必ず前に〜つけて」みたいなルールが違うところがあったり、覚えるのが大変。。。 「お前それ、あげる前にちゃんと動かした？」、「TODO残ってるんだけど？？？」みたいなことを逐一言うのは正直疲れるし、実装以外の部分の指摘をするためにコミット内容に目を通すのも時間がかかる。 少しでも「何か忘れてない？」チェックの負担を軽減できないかと思い、DengerFileと言うファイルで設定したルールの通りに自動チェックをしてくれる Dangerを導入をしてみた。 ※この記事は、CircleCI2.0が扱えると言う前提として書い
CircleCIのコンテナにSSHしてDebug - Qiita
目的 Githubにプッシュして, CircleCI上で自動テストを回してテストをして...。 ローカルではテストがオールグリーンなのに, CircleCI上ではなぜかテストが失敗する。 そんな時は, コンテナ内にSSHログインしてデバッグして見ると原因究明が捗る。 大抵は必要なモジュールが入っていなかったりといった, 環境の差異が多い コンテナにSSHログインする CircleCI側の作業 プルダウンから Return job with SSHを選択する Enable SSHの項目を展開すると, コンテナへ接続するためのSSHの情報が記述されている クライアント側の作業 自分の端末上でターミナルを起動して, 上記のSSH接続情報を入力する
Nuxt.jsで作った静的サイトのビルド/テスト/デプロイを自動化して、毎朝10時に更新する。
AWSとCircleCIの力を借りて、Nuxt.jsで作った静的サイトの運用をできるかぎり自動化した話です。 3ヶ月ほど前からCIのサービスを使うようになり、入門記事はたくさんあって助かったのですが、具体的にどんな感じで使っているかの情報が少なかったので記事にしました。 もしかしたら、CIの使い方が間違っているかもしれないので、そのときは優しくコメントをいただけたら嬉しいです。 できあがった流れ 毎朝10時にLambdaを起こしてデータの更新を行い、静的ファイルを再生成してからデプロイする流れになっています。 対象のサイト ざっくりAWSという、AWSの料金を日本円でざっくり計算できるサイトです。 Nuxt.jsで作成したものを、静的サイトとして生成して、AWSのS3にホスティングしています。 計算に必要なAWSの価格や為替は、毎朝10時に取得したものをS3にJSONで保存し、そのJSON
Docker で Bundler を使って Ruby の gem を作成する方法 - Qiita
プログラミングのツールやサービスは便利なものが揃っているので Ruby の gem を作りながら紹介します。 Docker なので OS X, Windows, Linux で動作します。 gem は Ruby の外部ライブラリです。 すること、できること Docker の Ruby で gem をテスト駆動開発で作ります。 CircleCI や CodeClimate のサービスで自動テストをします。 GitHub や RubyGems にリリースした gem を使います。 GitHub の利用 GitHub はソースコードを管理するサービスです。 今回は my_gems という名前の gem を作るので my_gems のリポジトリを作ります。 リポジトリを作ると続きはターミナルでコマンドラインを使います。 git init コマンドで空の README を追加をして、git conf
【iOS】match使わずにCircleCI2.0+FastlaneでFabric配布 - Qiita
概要 CircleCI2.0+Fastlaneでは証明書はmatchを使うのがデフォルトになっているらしい。 matchだとプライベートなリポジトリに証明書など一式アップしないといけないので、 今回はmatchは使わずにデプロイできるようにする。 セットアップ CircleCIでプロジェクトの設定をする 「ADD PROJECTS」>「対象のプロジェクト」>「Set Up Project」を選択 Operating SystemはmacOSでLaunguageはSwiftを選択し、Start buildingで設定します。 ローカルでFastlane初期化 references: defaults: &defaults macos: xcode: "X.X.X" working_directory: ~/project shell: /bin/bash --login -eo pipefa
Permission denied (publickey) on Travis.CI - Qiita
はい。タイトルで察した方もおられると思います。やっていきましょう。 Travis.CIは最初にgit clone --recursiveでレポジトリをクローンするため、submoduleがすべて自動的にクローンされていきます。ただ、ここでgitのデータ転送プロトコルとしてsshを使用していると、秘密鍵はレポジトリに置かれていないのでログインに失敗し、結果クローンが失敗します。そしてバッジが赤くなります。 これを何とかする方法として、そもそも常にhttpsを使えばいいんじゃないのという話なんですが、既にgit@...でsubmoduleを登録してしまっているし、CIのことはCIでしたいので、travis.yml上で解決しましょう。 早速ですが解決方法です。以下のtravis.ymlを見て下さい。 この方は何をしているかというと、まずTravisがgit clone --recursiveしな
RailsプロジェクトにささっとCircleCI2.0を導入する - Qiita
はじめに GithubでPull Requetを作成したら、masterにマージする前に自動でビルドされてテストやリンターが走ったら便利。実務ではデプロイツールと連携させたり、AWSやGCP、Slackなどと連携させたりしてさらに効率化を図るけど、ここではCircleCIだけをささっと導入する手順を書く。CircleCIで設定する環境と、実際にアプリを運用する環境をできるだけ合わせることがポイント。手軽に導入できて、設定もYAMLベースでできて簡単なので、CircleCIはとても良い。その他のCIツールとの比較記事はこちら 前提 Githubで管理しているRailsプロジェクトのリポジトリがある CircleCIのアカウントがある CircleCIとGithubを連携してある CircleCIのアカウントがなかったらCircleCIの公式サイトへ行ってサインアップ。CircleCIとGit
LaravelプロジェクトをCircleCI2.0でUIテストまで行う - Qiita
# PHP CircleCI 2.0 configuration file version: 2 jobs: build: docker: - image: circleci/php:7.1-jessie-node-browsers environment: APP_ENV: circleci APP_DEBUG: true DB_CONNECTION: sqlite working_directory: ~/repo steps: - checkout - run: sudo apt install -y libsqlite3-dev zlib1g-dev - run: sudo composer self-update - restore_cache: keys: - v1-dependencies-{{ checksum "composer.json" }} - v1-depende
CircleCIで、Firebaseのコマンドを実行させる方法 - Qiita
やりたいこと リモートプッシュ時に Firebase のデプロイコマンドを実行したい つまづいたこと CircleCI環境下で、firebase のコマンド実行につまづいた 解決法 CI環境下で、Firebase のデプロイをしたいので、firebase-toolsをインストールする必要があります。 最初に、グローバルでインストールしようとしましたが、CircleCI環境下では、それが許可されていません。(そりゃそうか) $ #!/bin/bash -eo pipefail npm install -g firebase-tools npm WARN checkPermissions Missing write access to /usr/local/lib/node_modules npm ERR! path /usr/local/lib/node_modules npm ERR! c
gRPCのコード生成をCircleCIで自動化する - Qiita
はじめに gRPCではクライアントとサーバーのインターフェースを一致させる事ができますが クライアントとスタブのコード生成がずれると通信できなくなります。 また各言語向けのprotocol buffer compilerを環境構築するのは面倒です。 そこで諸々の環境が揃ったDockerイメージのnamely/protoc-allとCircleCIを組合せてコード生成を自動化します。 構成 以下の図とブランチ構成でコード生成の自動化を行います。 masterブランチ .circleci/config.yml docker-compose.yml protos/echo.proto Go用のgenerated/goブランチ C#用のgenerated/csharpブランチ また実際の試したものは以下のリポジトリに置いています。 https://github.com/shiena/grpc-ge
GitLab CI/CD vs CircleCI
はじめに GitLab CI/CDとCircleCIの違いを比較する記事です。 GitLab CI/CDって何？ GitLab has integrated CI/CD pipelines to build, test, deploy, and monitor your code Rated #1 in the Forrester CI Wave™ Forresterに認められたNo.1 CIサービス。 GitLab supports development teams with a well-documented installation and configuration processes, an easy-to-follow UI, and a flexible per-seat pricing model that supports self service. GitLab’s
CircleCI上でng serveしながらCypressでテスト実行 - Qiita
タイトル通りですが、CircleCIでng serve（Angular）が必要なCypressのテストをする方法です (ドキュメント少ないけどCypressって流行ってないのかなぁ) なぜそんなことをしたいのか jestとかでmock（のデータはあったほうがいいと思うが）を作って、そのmockにmockであることを振る舞わせるのはなんだかテストしているようでしていないような（jest.fn()とか） なんか操り人形を使うことも記述しないといけないのが面倒だし結構複雑になる。。（ごめんなさい初心者です） ので、実際にlocalhostを立ち上げて、ちゃんと振る舞うかテストするのがmockの振る舞いも記述しなくていいのでテストしやすいと思ったのが背景です TL;DR Cypressでヘッドレスなテストを行う CircleCI上でlocalhostを立ち上げる CircleCIでng serve
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Dockerイメージの自動ビルドに, Automated BuildではなくCIを使う - Qiita
Werckerの環境変数やwercker.ymlで$(ドルマーク)を使う - Qiita
Java+GradleのアプリケーションをWerckerでビルドとテストする - Qiita
Java+Gradle+Wercker構成でCodecovによるカバレッジチェックする - Qiita
Travis CIとかtoxとかtestの話 - Qiita