はてなブックマーク

----- 2019/08/18 追記：GitHub Actions が新バージョンで大きく変わったため、新しい記事を書きました。こちらの記事は古い内容なので、新しい記事を参照してください。 www.kaizenprogrammer.com ----- developer.github.com 現在パブリックベータの GitHub Actions が自分も使えるようになったので、いろいろ調べたり動かしてみたりした内容をまとめます。 目次 注意事項 GitHub Actions とは 簡単な例 (Hello, World) ワークフローの設定 workflow ブロック action ブロック needs を使ったフロー制御 uses における Dockerfile の指定方法 ワークフローがサポートしているイベント 秘密情報の設定 GITHUB_TOKEN ビジュアルエディタ ワークフロー

github.blog 9/1 に GitHub Container Registry がパブリックベータとして公開されました。GitHub が提供する Docker レジストリサービスです。 この記事では、GitHub Container Registry についていろいろ調べたり動かしたりした内容をまとめます。 目次 注意事項 背景 Docker Hub と GitHub Container Registry GitHub Packages と GitHub Container Registry 料金 organization での GitHub Container Registry の有効化 試してみる パーソナルアクセストークンの作成 イメージの push イメージの権限変更 認証なしで public イメージの pull イメージの削除 GitHub Actions から Git

TL;DR 『GitHub Actions 実践入門』という、GitHub Actions の入門書を執筆しました。 miyajan.booth.pm BOOTH で PDF 版を 1,000 円で販売しております。A5 相当で 150 ページほどあります。ぜひお買い求めください！ 2020/03/15 追記 techbookfest.org 技術書典応援祭で PDF 版を 1,000 円、物理本 + PDF 版を 1,500 円（+ 送料 400 円）で販売しております！ 本の内容 概要 『GitHub Actions』の入門書です。 GitHub が提供する CI/CD サービスの GitHub Actions の基礎的な知識からはじめ、実際に活用してみるところまで扱います。 想定読者 GitHub Actions の入門者から中級者を対象としています。 この本は、以下の三点を意識しな

GitHub Actions Advent Calendar 2019 の 15 日目の記事です。 この記事では、GitHub Actions のキャッシュ機能について解説します。 目次 CI/CD とキャッシュ 簡単な例 (npm) 実験用リポジトリ作成 キャッシュ actions/cache Inputs と Outputs キーのマッチング順序 ビルド失敗時 キャッシュクリア 複数 OS で matrix ビルドするときのキャッシュ 言語ごとの例 アーティファクトとキャッシュの違い 制限事項 注意事項 まとめ CI/CD とキャッシュ CI/CD のビルドでは、リポジトリが依存するパッケージのダウンロードが原因でビルド時間が長くなってしまうことがよくあります。近年の CI/CD ではビルドごとに完全にクリーンな実行環境が用意され、前回のビルドでダウンロードしたファイルが持ち越されない

github.com 今回は、軽量で多機能な Selenium Grid である Selenoid についてまとめてみます。 目次 Selenium Grid とは？ Selenoid とは？ 軽量 セッションごとに Node が作成される 便利な機能 Getting Started Selenoid の起動 ステータスチェック テスト Live ブラウザスクリーン 録画 ログ取得 Selenoid の停止 Docker の推奨設定 ブラウザの設定ファイル その他の機能 まとめ Selenium Grid とは？ まず、いきなり Selenoid について書く前に、その前提となる Selenium Grid について簡単に説明します。 ブラウザテストの自動化などでよく使われる Selenium ですが、並列で複数のブラウザを使用して Selenium テストを実行するときに Seleniu

GitHub Actions 実践入門 (技術の泉シリーズ（NextPublishing）) 作者:宮田 淳平発売日: 2020/06/19メディア: Kindle版 これまで同人誌として販売していた『GitHub Actions 実践入門』が、インプレスR&D様から商業出版されました！ GitHub Actions 実践入門とは 『GitHub Actions 実践入門』は、GitHub Actions の入門書です。基礎的な知識から実際に動かしてみるところまで体系的に網羅しています。GitHub Actions を人に教えるときに、とりあえずこの本を渡しておけばいい内容になってるのではと思います。 元々は、今年 2 月に Booth や技術書典応援祭で販売した技術同人誌でした。同人誌版については、過去の記事を参照してください。 www.kaizenprogrammer.com 同人版を

Docker Hub の pull rate limit が 8 月に発表され、この記事執筆時点（11/15）で適用されつつあります。この pull rate limit の情報がいろいろなところに散らばっていてわかりづらくなってきたので、自分自身の情報整理のためにこの記事に現状をまとめてみました。 TL;DR 背景 Docker Hub の pull rate limit pull rate limit の回数カウントの定義 pull rate limit の適用スケジュール 現在の pull rate limit の確認方法 pull rate limit の例外 OSS サービス ミラー AWS ユーザー向け Docker Hub の public イメージの利用チェックツール Docker Hub の代替サービス まとめ TL;DR Docker Hub から pull するときは

概要 speakerdeck.com naoyaさんによる『System of Record と System of Engagement』というスライドをきっかけにバイモーダルITについて調べてみたらおもしろかったので、考察してみます。 バイモーダルIT バイモーダルITとは、ソフトウェアシステムを『信頼性が重視されるモデル』と『速度が重視されるモデル』に分けるプラクティスのことを指します。 前者のモデルをSystem of Record(SoR)と表すことがあり、主に情報を記録するシステムを指します。例えば、DBや銀行のアカウントシステムなどです。 後者のモデルをSystem of Engagement(SoE)と表すことがあり、主に顧客が直接触る部分のシステムを指します。例えば、SNSサービスのUIなどです。 それぞれのモデルによって特性が異なります。例えば、SoRならウォーターフォ

renovatebot.com Renovate が CircleCI Orbs に対応していることを思い出したので、まとめてみます。 CircleCI Orbs のバージョン更新問題 CircleCI Orbs は、一言で言うと CircleCI の設定をモジュール単位でパッケージ管理するための仕組みです。設定の共通化や再利用でとても便利です。 www.kaizenprogrammer.com CircleCI Orbs については過去に入門記事を書いたので、詳細はそちらをご参照ください。 個々の Orb は、基本的にセマンティックバージョニングでバージョンを管理しており、Orb の定義を .circleci/config.yml に記述するときは次のような指定方法があります。 cypress-io/cypress@volatile cypress-io/cypress@1 cypres

この記事は、Selenium/Appium Advent Calendar 2017 の 23 日目です。 この記事では、ブラウザテストツールの Cypress の紹介を Selenium ユーザーである自分の視点から書きます。 Cypress とは www.cypress.io Cypress は、テストのセットアップ、作成、実行、デバッグなどをシンプルにするブラウザテストツールです。E2E テストを既存の Selenium のようなツールで実装・運用するときにありがちな辛い体験を改善して、開発者を幸せにすることが目的のようです。 Cypress は、3 年以上の間 private beta だったのですが、今年の 10 月に public beta になり、そのタイミングで大半が OSS となりました。 www.cypress.io Cypress は、ThoughtWorks 社の

この記事は、CircleCI Advent Calendar 2018 初日の記事です。記事公開時点ではまだ空いてる日程があるので、CircleCI に関するネタならなんでも気軽に参加してください！ 長いので目次。 Orbs とは？ 事前準備 2.1 の有効化 Orbs のセキュリティ設定 CircleCI CLI 公開されてる Orbs を利用する Orbs を公開する Namespace の作成 Orb の作成 Orb の中身の作成 Orb のバリデーション Orb の公開 公開された Orb の確認 Orbs Registry まとめ Orbs とは？ Orbs は、最近 CircleCI 2.1 として追加された機能の一部で、CircleCI の設定をパッケージとして公開し、再利用するための仕組みです。2.1 も Orbs もまだプレビュー段階ですが、後述する設定を有効にすれば利用

github.com まだプレビューですが CircleCI の新機能が 2.1 として使えるようになっているという話と、2.1 の新機能で yaml の設定を DRY にする方法を紹介します。 長いので目次。 2.0 までの DRY な yaml を書く方法 2.1 を有効にする方法 2.1 の新機能 Commands Executors ジョブのパラメータ化＆ワークフロー内での複数回実行 Conditional Steps Orb CLI の変更 まとめ 2.0 までの DRY な yaml を書く方法 2.0 までは CircleCI の yaml の設定を DRY にしようとすると yaml のエイリアスを使う必要がありました。 例えば、node.js のプロジェクトで node の複数バージョンでビルドする設定をエイリアスで DRY にしようとすると次のようになります。 node

Jenkins 2.0について書く記事の3回目です。今回は、前回書いたJenkins Pipelineを構成するDSLについて書きます。 フリースタイルプロジェクトのジョブ設定 1.x時代から存在したフリースタイルプロジェクトでは、Web上のUIを通してジョブを設定しました。この方法は、前回書いたように、わかりやすい反面いくつか問題点もありました。 機能が増えるにつれ設定UIが複雑になりがち 1つのジョブにつき1つのノードしか使えない デプロイパイプラインを構築するためには複数ジョブをつなげないといけない 設定の変更履歴を管理しづらい Scripted Pipeline 2.0のPipelineでは、GroovyによるDSLが導入され、Pipeline as Codeとしてジョブを設定できるようになりました。DSLによる柔軟な表現力により、上記の問題が改善されました。 必要な設定だけコード

Jenkins 2.0について書く記事の4回目です。今回は、GitHub連携について書きます。 GitHub連携でやりたいこと 昨今の一般的なCIサービスでは、GitHub連携に求められることは以下になります。 リポジトリにpushしたら自動でビルド開始される ビルド結果をcommit statusへ反映 ちなみに、commit statusとは↓のようなGitHub上でコミットの状態を可視化してくれるすばらしいものです。 1.0時代のGitHub連携 過去のJenkinsのフリースタイルジョブで上記のようなGitHub連携を実現しようと思うと、GitHub Pluginをインストールした上で次のような設定が必要でした。 「Jenkinsの管理」→「システムの設定」→「GitHub」→「GitHub Servers」で「Add GitHub Server」 事前にGitHub側で “rep

技術評論社様から本日 9/14 発売の『CircleCI実践入門』を、著者の一人である金さんから献本いただきました。一通り読んだので、印象に残ったところなどをまとめておきます。 CircleCI実践入門──CI/CDがもたらす開発速度と品質の両立 (WEB+DB PRESS plus) 作者:浦井 誠人,大竹 智也,金 洋国発売日: 2020/09/14メディア: 単行本（ソフトカバー） 本の概要 『CircleCI実践入門』は、WEB+DB PRESS Vol.107 で特集『実践CircleCI』を執筆した浦井さん（@uraway_）と大竹さん（@tomoyaton）に加え、CircleCI 社 SRE の金さん（@kimhirokuni）の 3 名で執筆されています。 CircleCI の使い方の解説はもちろんのこと、CI/CD とはなにか、近年のアジャイルや DevOps の文脈の

過去に、『CircleCI 2.0 で定期実行ジョブ（Nightly Builds）を実現する』という記事を書いたのですが、現在の CircleCI 2.0 ではもっと楽に cron 的な定期実行ジョブを記述できるようになっているので補足記事を書きます。 前の記事を書いた時点では CircleCI 自体にジョブ実行タイミングをスケジュールする機能がなかったので、外部の Lambda なりなんなりを使って API を叩くという遠回しな手段をとっていましたが、今では Workflows に "triggers" という構文が追加されているので、CircleCI のみで完結して定期実行ジョブを記述できるようになっています。 circleci.com ↑の記事を見てもらうのが一番わかりやすいと思いますが、英語しかないので一応こちらでも解説します。 version: 2 jobs: build: d

『Concourse CI/CD Meetup Tokyo #3』に参加してきたので、そのまとめを書く。遅刻して最初の発表を聞けなかったので、チラシの裏レベルのレポート。発表資料などが上がり次第更新する。 Concourse Update (Etourneau Gwenn, Pivotal) Concourse updates from Gwenn Etourneau www.slideshare.net 遅刻して残念ながら聞けなかった・・・ Concourse CIのバージョンアップの変遷を知ることができる内容だったっぽい TEAM support in ConcourseCI (Toshiaki Maki, Pivotal Japan, Pivotal) Team Support in Concourse CI 2.0 #concourse_tokyo from Toshiaki Ma

この記事は、Selenium/Appium Advent Calendar 2016の18日目の記事です。17日目は、xshsakuさんのAppiumとSTFを使ったAndroid実機テストでした。 はじめに Seleniumテストを運用する上で安定性は大事です。テストが不具合以外の原因で頻繁に失敗してしまうと、チームメンバーは段々テスト結果を気にかけなくなってしまいます。そうなってしまうと、いざ不具合でテストが落ちても気づかれずに後回しになってしまう恐れがあります。自動テストの目的が問題の早期発見であることを考えると、これは深刻な問題になります。 この記事では、Seleniumテストが不安定になりやすい要因とその対策を、自分の経験の中からまとめてみます。 環境 Seleniumテストは、テストコードを実行するマシンさえあればいい単体テストと異なり、様々な環境が必要となります。そのため、不

これまで GUI から行っていた Jenkins のシステム設定を yaml で設定できる Configuration as Code プラグインについて解説します。 github.com これまでの Jenkins as Code 〇〇 as code は近年いろいろなところで見かけますが、設定をコード化するとソフトウェア開発のプラクティスを適用できるようになり、以下のようなメリットがあります。 バージョン管理できる 変更を追跡できる 変更に問題があったときに素早く前の状態に戻せるので安全 GUI では設定が多いときに時間がかかるけど、コードで自動化されれば高速 簡単に再利用できる Jenkins にも as code の波は来ています。例えば Docker を使えば Jenkins の master の環境構築をコード化できますし、ジョブの設定は Jenkinsfile を使えば gr

Jenkins 2.0のDeclarative Pipelineには、Jenkinsfileをlintするための仕組みが用意されています。 curlとssh プラグインのWikiには、sshとcurlそれぞれでJenkinsをlintするための方法が紹介されています。以下は引用です。 # ssh方式 ssh -p [sshd port on master] [Jenkins master hostname] declarative-linter < Jenkinsfile # curl方式 curl -X POST -H `curl 'JENKINS_URL/crumbIssuer/api/xml?xpath=concat(//crumbRequestField,":",//crumb)'` -F "jenkinsfile=<Jenkinsfile" JENKINS_URL/pipelin

CircleCI 2.0 の小ネタです。 TL; DR リポジトリのルートに Dockerfile がある前提です。 CircleCI 2.0 で対象のリポジトリをプロジェクトとして有効にする CircleCI 2.0 上で環境変数に Docker Hub のユーザー名を DOCKER_USER に、パスワードを DOCKER_PASS に登録する .circleci/config.yml に以下のように記述する version: 2 jobs: build: docker: - image: docker:17.07.0-ce-git steps: - checkout - setup_remote_docker - run: command: docker build -t miyajan/test-circleci-docker . - run: command: docker lo

circleci.connpass.com 1/30（水）に DeNA さんのオフィスで開催された『第 1 回 CircleCI ユーザーコミュニティ ミートアップ』に参加してきたので、簡単に参加レポートです。 twitter のハッシュタグは #circlecijp です。 CircleCI ユーザーコミュニティについて speakerdeck.com はじめに、CircleCI のカントリーマネージャーである森本さん（@kemorimo）から CircleCI ユーザーコミュニティについての説明と、今回会場提供もしているコミュニティリーダー DeNA 井口さん（@hisa9chi）からの挨拶がありました。 circlecijp = 「学ぶ」と「つながる」が両立する場 Learn: 機能だけでなく、運用の話も Connect: うまく使っている人だけでなく、これから使う人の HUB に

2018/02/11 追記 この記事に書かれている内容は古いので、補足記事を書きました。この記事の方法を使うメリットは現時点でほぼないはずなので、以下の記事を参照してください。 www.kaizenprogrammer.com 今回は、CircleCI の小ネタです。 CI を行っていると、cron 的な定期実行ジョブを実現したいときがあります。例えば、毎回実行される CI/CD に入れるには重すぎる、セキュリティチェックや性能検証などを夜間にデイリーで実行したいような場合です。今回は、CircleCI 2.0 で定期実行ジョブを実現する方法について書きます。 CircleCI 1.0 まず、これまでとの比較のために CircleCI 1.0 のときにどうやって実現していたかを書きます。CircleCI 1.0 のときは、公式ドキュメントの Nightly Builds というページに定期

はじまり 一人暮らしを始めてから長らく、自宅に本格的な開発環境というものは整えてこなかった。開発環境というのは、主に机、椅子、モニタといったものである。 理由は簡単で、部屋が狭いから。1Kの部屋にはすでにベッド、テレビ、ソファーやカラーボックスがあって、まだギリギリPCデスクを置けなくもないけど、置いたら誰か人を呼んだりとかはできなくなるので嫌だった。昔からの友人と麻雀したり、飲んだりとかそういうことができなくなるのが嫌だった。 しかし、なぜか最近になってそういうことはどうでもいいかなと考えるようになった。別に、麻雀とか飲みとかなら外でやればいい話だし、そもそも30も近づいてくると周囲が家庭持ちとかになってきて、休日にそんなことやろうと言い出す友人も減ってきた。むしろ、がっつりコードなり文章なり書きたいときにノートPCを膝の上に置いた窮屈な姿勢をとることの辛さのほうが増してきた。 というわ

Jenkins Pipeline についての小ネタメモです。 まず、when + branch の条件について簡単に説明しますと、ビルドが特定のブランチに対して実行されるときだけ処理を実行するように書ける文法です。 pipeline { agent any stages { stage('Example Build') { steps { echo 'Hello World' } } stage('Example Deploy') { when { branch 'production' } steps { echo 'Deploying' } } } } ↑の例をマルチブランチパイプラインジョブで実行すると、production ブランチに対してトリガされたときだけ “Example Deploy” ステージが実行されます。 しかし、これを通常のパイプラインジョブで実行すると、ブランチに