2019-09-28

circleci-bundle-update-prをGitHub Actionsで動かせるようにした

github Ruby

投げたPRはこちら

github.com

動機

とある事情でCI用途のパーソナルアクセストークンを撲滅したかった件の一環です。

解説

GitHub Actionsはジョブ実行時に自動でアクセストークンをセットしてくれて便利なんですが、API実行の許可は付与されていても git push に対する許可が与えられていませんでした。

具体的には下記がGitHub Actionsだとエラーになります。

https://github.com/masutaka/circleci-bundle-update-pr/blob/v1.16.1/lib/circleci/bundle/update/pr.rb#L104-L111

そこでシステムの git で git commit と git push してる部分をAPIで置き換えた感じです。

circleci-bundle-update-prをGitHub Actionsで動かす方法

https://github.com/masutaka/circleci-bundle-update-pr#run-on-github-actions にも書いたようにGitHub Actionsの変数をCircleCIの変数でexportしなおしてあげるだけでGitHub Actionsで動くようになります。

実際にGitHub Actionsで動かした図がこちら

f:id:sue445:20190928003300p:plain

補足

執筆時点では

steps:
  - name: Set up Ruby
    uses: actions/setup-ruby@v1
    with:
      ruby-version: v2.6.4

のように書いてもRuby 2.6.4をインストールできないため *1、 Gemfile で ruby "2.6.4" を書いているとかでどうしてもRuby 2.6.4を使いたい場合には

container:
  image: ruby:2.6.4

のようにDockerイメージを使うのがいいと思います。

circleci-bundle-update-prをGitHub Actionsで動かすメリット

パーソナルアクセストークンの発行が不要になる
CircleCIがorg単位での並列数に対してGitHub Actionsがリポジトリ単位での並列数なので、複数リポジトリで同時にジョブが実行されても詰まらない

circleci-bundle-update-prをGitHub Actionsで動かすデメリット

GitHub Actionsにはキャッシュがないため、毎回フルでbundle installが実行されて遅い
- schedulerで定期的に動かすジョブなので少々遅いのは個人的には許容できる
- Betaなのでキャッシュがないと割り切っています（楽観）

余談1

gitlabci-bundle-update-mr で同じ方針でやったので余裕かと思ってたら、GitLabだとAPI 1回で済んだことがGitHubだとAPI 7回もかかって意外に手ごわかった、、、

余談2

dependabotでええやんっていうのもごもっともなんですが、dependabotだと1 bundle update 1 PRになっている関係でPRが大量にきた時にCIが詰まるという問題があるので個人的には circleci-bundle-update-pr くらいの粒度が好きです。

あと、circleci-bundle-update-prだと下記のようにすることで週替りでbundle update当番を割り当てることができるんですが、dependabotだと同じことができない（assigneesが固定値しか渡せない）ためcircleci-bundle-update-prを使い続けてるというのもあります。

circleci-bundle-update-pr --assignees $(ruby -rtime -e 'a=%w[foo bar baz]; print a[Time.now.to_date.cweek% a.size]')

*1:https://github.com/actions/setup-ruby/issues/24

2019-09-26

【CVE-2019-10429】 Jenkins GitLab Logo Plugin v1.0.4をリリースした

security

作ったきり特にメンテしていなかった Jenkins GitLab Logo Plugin ですが、Jenkinsチームから脆弱性の報告を受けたので修正しました。

jenkins.io

https://jenkins.io/security/advisory/2019-09-25/#SECURITY-1575 にも書いてますが、GitLabのprivate tokenを暗号化せずにそのまま保存していたので暗号化して保存するようにしています

バージョンアップ時の注意点

Global configをsaveするだけで暗号化されて保存されます

日本語の関連記事

blog.trendmicro.co.jp

その他

CVEは採番されてないですが Jenkins ChatWork plugin も同様の問題を抱えていたためv1.0.9で修正しています

2019-09-21

GitLab CIでTerraformを動かす

GitLabCI Terraform

GitLab CIでTerraformをいくつか動かしてるのですがGitLab CI独自の機能をうまく使うといい感じにCIができるようになったのでメモ

前提
ベースになるジョブをincludeで別リポジトリから読み込むと便利
Terraform実行専用のRunnerを作る
- limit = 1 にする理由

前提

AWSの各アカウントをTerraformで管理している
アカウントごとにTerraformのリポジトリを作成
- 1アカウント = 1リポジトリ
masterブランチ以外では terraform plan を実行し、masterブランチで terraform apply を実行
- terraform plan があまり信用できないから別アカウントへの terraform apply のパターンもあるかもしれないですが、 terraform plan の方が基本形かなと思ってます

ベースになるジョブをincludeで別リポジトリから読み込むと便利

includeとはGitLab 11.4にcoreに入った機能で、外部のCI設定を .gitlab-ci.yml に取り込む機能です。

https://docs.gitlab.com/ee/ci/yaml/#include

他のCIサービスでいうとCircleCIのorbsが一番近いです。

include導入前

includeを使う前は各リポジトリに下記のような .gitlab-ci.yml が点在していました。

.terraform: &terraform
  image:
    name: hashicorp/terraform:0.12.5
    entrypoint: [""]

  before_script:
    - terraform init -input=false

  tags:
    - terraform

stages:
  - test
  - deploy

cache:
  key: "${CI_JOB_NAME}"
  untracked: true
  paths:
    - .terraform/

tflint:
  <<: *terraform

  stage: test

  variables:
    TFLINT_VERSION: "0.9.2"

  script:
    # tflintのDockerイメージを使うとterraform initできなくてmoduleが読めないためバイナリをDLする
    - cd /tmp
    - wget https://github.com/wata727/tflint/releases/download/v${TFLINT_VERSION}/tflint_linux_amd64.zip
    - unzip tflint_linux_amd64.zip

    - ./tflint

  tags:
    - docker

terraform-plan:
  <<: *terraform

  stage: test

  script:
    - terraform plan -input=false

  except:
    - master

terraform-apply:
  <<: *terraform

  stage: deploy

  script:
    - terraform apply -input=false -auto-approve

  only:
    - master

terraform-apply-manual:
  <<: *terraform

  stage: deploy

  script:
    - terraform apply -input=false -auto-approve

  except:
    - master

  when: manual

2箇所くらいならまだ許せたのですが4つ超えたあたりで厳しい感じになりました

include導入後

先日会社のGitLabをバージョンアップしたので includeを使ってリファクタリングしました。

まずは下記のようにテンプレートファイルのみを用意したリポジトリを用意

variables:
  TERRAFORM_VERSION: ""
  TFLINT_VERSION:    ""

.terraform:
  image:
    name: hashicorp/terraform:${TERRAFORM_VERSION}
    entrypoint: [""]

  before_script:
    - terraform init -input=false

  tags:
    - terraform

stages:
  - test
  - deploy

cache:
  key: "${CI_JOB_NAME}"
  untracked: true
  paths:
    - .terraform/

tflint:
  extends: .terraform

  stage: test

  script:
    # tflintのDockerイメージを使うとterraform initできなくてmoduleが読めないためバイナリをDLする
    - cd /tmp
    - wget https://github.com/wata727/tflint/releases/download/v${TFLINT_VERSION}/tflint_linux_amd64.zip
    - unzip tflint_linux_amd64.zip

    - ./tflint

  except:
    - master

  tags:
    - docker

terraform-plan:
  extends: .terraform

  stage: test

  script:
    - terraform plan -input=false

  except:
    - master

terraform-apply:
  extends: .terraform

  stage: deploy

  script:
    - terraform apply -input=false -auto-approve

  only:
    - master

terraform-apply-manual:
  extends: .terraform

  stage: deploy

  script:
    - terraform apply -input=false -auto-approve

  except:
    - master

  when: manual

Terraformリポジトリでは下記のように別リポジトリのtemplateを呼び出すだけで使えるようになります

include:
  - project: "group/gitlabci-terraform-template"
    file:    "/template.yml"

variables:
  TERRAFORM_VERSION: "0.12.5"
  TFLINT_VERSION:    "0.9.2"

メリット

CIの設定を一箇所に集約したことにより、利用側ではTerraformとtflintのバージョンだけ渡すだけで使えるようになる

上記templateでやってること

masterブランチ以外では terraform plan と tflint を自動実行しつつ、必要なら terraform apply を手動実行

f:id:sue445:20190920235810p:plain

masterブランチでは terraform apply を自動実行

f:id:sue445:20190920235819p:plain

Terraform実行専用のRunnerを作る

前述の設定で tags に terraform を書いてたやつです。

このTerraform専用のRunnerですが、下記のようにlimitを1にしたdocker executorを作っています。

[[runners]]
  name = "terraform"
  executor = "docker"
  limit = 1

https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section

`limit = 1` にする理由

AWSでTerraformを使う場合にはbackendをs3にしつつ、DynamoDBで排他ロックをかけるのがデファクトになってます。

www.terraform.io

しかしこれだと同時に2つのブランチをpushした場合に後から実行された方が排他ロックエラーになってジョブが失敗します。

Terraformを触る人数が多いとこの手のエラーはしょっちゅう起こるし、1人しか触ってない場合でもトピックブランチをpush後にミスに気づいてforce pushしたような場合にもエラーになります。

それを防ぐためにRunnerを limit = 1 にする（つまり複数のジョブの同時実行をさせない）ことでジョブが確実に1つずつ実行されるようになり、さっきのような排他ロックエラーを回避できます。（planの時だけロックかけないってのも頑張ればできそうだけど怖いのでやったことはない）

ちなみにジョブの並列実行数を意図的に制限するというのは僕が知る限りGitLab CIでしか実現できない機能です。（少なくともTravis CI, CircleCI, Wercker, GitHub Actionsには存在しないです）

このTerraform専用Runnerはここ1年くらいずっと使っていますが、CircleCIでTerraformを動かしてた時によく起こってた排他ロックエラーが一切発生しなくなったのでおすすめです。

2019-09-09

CIマニアから見たGitHub Actions(Beta)の使い所

CI github GitHubActions

1ヶ月くらい使って勘所が見えてきたのでメモ

メリット
実際にGitHub Actionsに移行したプロダクト
デメリット
- yamlのanchorが使えない
- マトリクステストだとSlack通知がつらい
合わせて読みたい

メリット

1リポジトリ辺り20並列までジョブを並列実行できる

これに尽きる。

CircleCIにしろTravis CIにしろorganization(user) *1単位で並列数が縛られているため、例えば同じuserの他のリポジトリでジョブが詰まっていると別リポジトリではqueueが詰まってジョブが実行されません。

しかしGitHub Actionsの場合リポジトリ単位で並列数が縛られているので、あるリポジトリで20並列ジョブ実行中だからといって他のリポジトリでジョブが詰まることがありません。

後の方でデメリットについて色々書いてるけど、このメリット1つだけで他のデメリットを帳消しにしてお釣りがくるくらいの破壊力はあります。（偏見）

ジョブ実行時はアクセストークンが勝手に設定されている

CIのジョブの中でGitHubのAPIを使いたい場合、パーソナルアクセストークンを発行してsecretsとかにセットすると思うのですが、GitHub Actionsだと secrets.GITHUB_TOKEN に勝手にセットされているので発行する必要がないです。

特に会社系のorganizationの場合、誰かがジョブ実行用のパーソナルアクセストークンを発行してCIを設定してその後その人が退職してorganizationから外された後にCIが動かなくなるってことが割とよくあると思うのですが（僕は過去2～3回見てきました）、その心配がなくなるのは地味に嬉しいところ。

マトリクステストがやりやすい

Travis CIライクな記法が使えるのでマトリクスの軸が増えてもyamlが長大になりづらいというメリットがあります。

jobs:
  build:
    strategy:
      matrix:
        ruby:
          - v2.3.x
          - v2.4.x
          - v2.5.x
          - v2.6.x
        gemfile:
          - gemfiles/rails_4_0.gemfile
          - gemfiles/rails_4_1.gemfile
          - gemfiles/rails_4_2.gemfile
          - gemfiles/rails_5_0.gemfile
          - gemfiles/rails_5_1.gemfile
          - gemfiles/rails_5_2.gemfile
          - gemfiles/rails_6_0.gemfile

最初に書いた1リポジトリ辺り20並列の仕様もあるのでライブラリ作者的に嬉しい。

実際にGitHub Actionsに移行したプロダクト

時系列順に紹介

zatsu_monitor

github.com

元々はTravis CIを使ってたんですが、僕の他リポジトリで採用してる「gitのtagをpushしたらCI上でバイナリをビルドしてReleasesに自動アップロードするお手軽リリース」がなくて割と面倒でした。

そのうちTravis CIで実装しようかと思ってた矢先にGitHub Actionsが使えるようになったので移行してお手軽リリースを実装しました

activerecord-compatible_legacy_migration

github.com

僕がメンテしてるgemの中で2番目にマトリクス数がヤバかったやつ。（Travis CIで40個）

並列数は多いものの後述のindex_shotgunと違ってMySQLやPostgreSQLのようなDBを使ってないのでGitHub Actionsで初マトリクステストやるには丁度よさそうな規模感と難易度と踏んで移行

index_shotgun

github.com

僕がメンテしてるgemの中で1番マトリクス数がヤバいやつ。

マトリクス数はTravis CIだけで50個くらいあって、歴史的経緯でCircleCIも併用してるのでそれも合わせると55個くらいあります。

なんでマトリクス数がこんなにヤバいのかというと「各Rubyのバージョン x 各activerecordのバージョン x 各DB(sqlite3, MySQL, PostgreSQL, Oracle)」でテストしてるため。

複数のCIを併用してる弊害として .circleci/config.yml だけ修正したのにTravis CI側でもジョブが実行されて30分くらい待たされるという事象が度々あったので、CIを1つにまとめたいとは思ってました。

実際にGitHub Actions対応を行ったのが下記PRですが、Railsで使えるdatabase.ymlをテストコードで使っているので普通のRailsアプリをGitHub ActionsでCIする時の設定は参考になると思います。

github.com

ちなみにGitHub Actions移行後はマトリクス数60個くらいですが、全部実行し終わるための所要時間は18分前後です。

デメリット

Betaクオリティなので大目に見てますが、大目に見た上でもここはつらいというところだけ書いてます

yamlのanchorが使えない

Railsのdatabase.ymlでよく見る

default: &default

development:
  <<: *default

的なやつ。

yamlファイルが一定規模以上になるとanchorとmergeを使って上記のようなリファクタリングをしてDRYにしたくなるのですが、GitHub Actionsだと「Anchors are not currently supported」というエラーになって使えなくてつらい。

f:id:sue445:20190909225037p:plain

anchorとmergeでリファクタリングできるのがYAMLの特徴だと思うんだけど、それが（まだ？）使えないのが残念。

マトリクステストだとSlack通知がつらい

GitHub ActionsにSlack通知機能が搭載されていなくてstepの中で自分でSlack APIを叩くかmarketplaceにあるSlack通知用のCheckを使うことになります。

しかしマトリクステストのstepsの中で直接Slack通知を行うと通知が大量にきてノイズになるので、全てのマトリクステストが終わった後に1回だけ成功か失敗かの通知を投げてほしいと思うのが人情ですが、それを実装するのが今のGitHub Actionsの仕様だと非常に面倒です。

上記要件を真面目に満たそうとするとこんな感じになります。

jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        # 略

    steps:
      # 略

      - name: Slack Notification (not success)
        uses: homoluctus/slatify@v1.5
        if: "! success()"
        with:
          job_name: '*build*'
          type: ${{ job.status }}
          icon_emoji: ":octocat:"
          url: ${{ secrets.SLACK_WEBHOOK }}

  notify:
    needs: build
    runs-on: ubuntu-latest

    steps:
      - name: Slack Notification (success)
        uses: homoluctus/slatify@v1.5
        if: always()
        with:
          job_name: '*build*'
          type: ${{ job.status }}
          icon_emoji: ":octocat:"
          url: ${{ secrets.SLACK_WEBHOOK }}

needs を使えば前のジョブが全部終わった時に次のジョブを実行するというworkflowが組めるのでこれを使えばマトリクステストが全て終わった時にnotify ジョブで1回だけ通知を飛ばすということが簡単にできそうに見えます。

しかしneedsに書いたジョブが全て成功した時にしか実行されないので notify ジョブだけだとジョブ成功時の通知しか飛ばせません。

そのためマトリクステストの中で失敗時の通知を飛ばすような実装が必要になります。

GitHub ActionsのマトリクステストはTravis CIと違ってfail-fast（マトリクステストがどれか1つでも失敗したら他はスキップする）という仕様なのでジョブ失敗時の通知は1回しかこないように見えますが、同時に20並列もテストを実行してるとだいたい同時にテストが失敗するため失敗時の通知は複数飛んできます。

ジョブ失敗時はだいたい10個くらい同時に通知が飛るのですが、他にやりようがないので今は我慢してます、、、

f:id:sue445:20190909231009p:plain

合わせて読みたい

sue445.hatenablog.com

*1:ここで言ってるuserというのはジョブの実行者ではなくリポジトリの所有者の方です

2019-09-05

zatsu_monitor v1.0.0をリリースした

golang

リリースノート

https://github.com/sue445/zatsu_monitor/releases/tag/v1.0.0

Breaking changes

zatsu_monitorは今まで 0.3.3 のようなtagをつけていたのですが、Go modulesがprefix付きのtagを推奨していたので *1 、それに準拠して v1.0.0 のようなtag名に変更しました

アプリ的な機能変更は特にない（強いて言うならGo 1.13へのアップデートとライブラリのアップデートくらい）のですが、プロビジョニングツールとかからReleasesのバイナリをDLしてるケースもあるので *2 念の為Breaking changes扱いにしています。

*1:https://github.com/golang/go/wiki/Modules#modules

*2:自分のItamaeレシピでやってる

2019-08-16

よいコミットメッセージを書くために心がけていること

よいコミットメッセージとはどういうものだろう？ - chiastolite’s blog に対するアンサーソングです

chiastolite.hatenablog.com

必要であればWhyを補足するためのContextを書く

元エントリだとコミットメッセージの話だったけど僕はPRで実践してもいいと思います。*1

起点となるURLを明記する

レビューで指摘されたのであればPRのコメントのURL
issueのURL
アプリケーションエラーであればSentryなどのエラートラッキングシステムのURL
GitHub外のタスク管理ツール（例：redmineやBacklogやTrelloなど）に修正概要が書かれているのであればそのURL
チャットのやり取りが起因ならSlackなどのパーマリンク
公式ドキュメントのURL
CIがコケているのであればCIのビルドのURL

チーム開発していればコミットやPRを行う起点となるURLがだいたいの場合存在するので、僕はそれを書くようにしています。

理由

コミットメッセージやPRにWhyを全て書くのは難しいのでそれに付随するContextは別URLを参照させた方が楽
特にチャットのやり取りの場合、その当時のリアルなやり取りをコミットメッセージやPRの概要で読み取るのは難しいのでSlackのURLが貼られていると後々他の人が見た時の情報が増える

別に他人に強制するようなものでもないし *2即効性がない（1～2年後の誰かが嬉しくなる可能性があるだけ）のですが、自分がこうされていると嬉しいので日頃からやっています

アプリケーションエラーやCIのビルドエラーであればバックトレースも（全部じゃないけど）書く

これは場合によりけりかな。

SaaSは過去ログが全部残ってることが多いので1年後とかにそのURLを見返すことができます。

しかしSentryやGitLabなどを自前でホスティングしてるような場合に容量的な問題で過去ログを定期的に消していることがあるので、そういった場合にURLだけだとリンク先が消えて詳細な情報が追えなくなるので僕は念の為書くようにしています。

*1:僕は両方やったことある

*2:さすがにコミットメッセージの書き方まで細かく指摘はしない

2019-08-15

condo3と地域.rbカレンダーを作った

golang appengine Ruby

夏の進捗です。

令和の夏、進捗の夏
— sue445 (@sue445) 2019年8月11日

condo3
地域.rbカレンダー
- 技術的なこと
- メリット
8/15 16:50追記

condo3

condo3について

connpassやDoorkeeper のグループのイベント情報をiCalendarやAtomで取得するためのサイトです

https://condo3.appspot.com/

f:id:sue445:20190811162205p:plain

モチベーション

connpassやDoorkeeperで特定のグループ（コミュニティ）の勉強会をウォッチするのに現状だと開催通知のメールしかないのが不便という問題がありました。（個人的にはSlackでウォッチする手段がほしかった）

本当は公式でこの手の機能（グループ単位のフィード）を提供してほしかったんですが、connpassには（Doorkeeperだったかも？）過去に要望投げたものの特に音沙汰がなかったので結局自分で作りました。

ユースケース

AtomのURLをSlackの特定のチャンネルで /feed subscribe 〜 すれば新しいイベントが作られた時にSlackに通知される
iCalendarのURLをGoogleカレンダーに登録すれば自分のカレンダーに表示できる。
- さらにGoogleカレンダーをSlackに連携させればSlackに通知もできる

ここではSlackとGoogleカレンダーのみ取り上げていますが、AtomもiCalendarも汎用的な規格なのでこれらの形式に対応している他のツールと連携させることもできます。

技術的なこと

リポジトリ

github.com

アプリ本体でいうと開発期間は全部で3週間くらい
- サーバサイド2週間 + フロントエンド1週間 + 細かい調整で3日弱
- 他に https://github.com/sue445/go-doorkeeper の開発で2〜3日。（condo3作ってる最中にDoorkeeperのgolang用のAPIクライアントがないのに気づいて作った）
サーバサイド
- Go 1.12
- GCP
  - Google App Engine/Go
  - Cloud KMS
- memcached
フロントエンド
- Vue.js
- TypeScript
- webpack
- Bulma （CSS フレームワーク）

余談ですが個人開発だとCloud KMS, TypeScript, webpack, Bulma辺りは初採用です

技術の選択理由

Google App Engine/Go
- アプリの性質上無限にAPIを叩かれることが容易に想像できたので、Herokuはあまり使いたくなかった
  - Herokuはアカウント単位でDyno hour（インスタンス起動時間）の無料枠を使うため。（既にHerokuで個人アプリ10個以上動いてるのでリクエストがガンガンくるアプリは立てたくない）
- 業務的な話になるけど今期の個人目標が「GCPのスキルをつける」だったのでせっかくだからappengineを使ってみるかってことに
  - appengineは昔使ってたことがあるので全然知らないわけではなかった
- appengineではいくつか言語が選択できるけど、爆速でリクエストさばくにはGoが一番向いてた
フロントエンド
- 自分の中ではReactかVue.jsの二択だったけど、APIがメインで画面はトップページしか必要なかったのでVue.jsを選択
  - Reactは大規模開発のイメージがあった。（異論は認める）
- 型安全が好きなのでTypeScript選択
CSSフレームワーク
- Bootstrap以外思いつかなかったので社のSlackで募集したうちの1つがBulma
- 実際に社のSlackに投げた時のスクショが下記

f:id:sue445:20190811165356p:plain

開発時に苦労したこと

8〜9年ぶりにGoogle App Engineを触ったので浦島太郎状態
特にappengine/GoはGo 1.11(1st generation)と1.12(2nd generation)で作り方が全然違う *1 のを知らずに最新版って理由だけで1.12で作り始めたので、1.12のドキュメントも少なくググった時に1.11以前のドキュメントが出てきて動かなくてそこでハマってた
- 2nd genだとローカル開発時に dev_appserver.py が不要になってたり、appengine本体にmemcachedが入ってないのが一番のハマりでした...
フロントエンド赤ちゃんの状態で雰囲気でVue.jsやTypeScriptを書いたのでハマりしかなかった

名前の由来

connpassの con とDoorkeeperの do を足してcondo3です。

末尾の3に関しては諸説ありますが語呂が良かった説が一番有力です。（他にもappengineで作った3つ目のwebアプリだったり、appengine/Javaで使ってたSlim3というフレームワークにあやかったという理由もある（今思いついた））

地域.rbカレンダー

condo3の副産物です。日本各地の地域.rb情報がひと目で分かるカレンダーです

https://sue445.github.io/regional-rb-calendar/

f:id:sue445:20190815120012p:plain

github.com

技術的なこと

condo3のiCalendarのURLをGoogleカレンダーにインポートして表示させただけ。

僕が見つけた地域.rbは全部登録したけど漏れがあると思うのでその場合は issue で教えてください。

メリット

一度iCalendarのURLをGoogleカレンダーに登録してしまえばあとは勝手に最新の情報に追従され続けるのでメンテが楽

8/15 16:50追記

わかりにくくて申し訳ありませんが、実は connpass では、グループごとにイベント一覧のフィードをご提供しております。わかりにくくて…申し訳ありません…
例) https://t.co/7GRqbPA9y0
— connpass (@connpass_jp) August 15, 2019

知らなかった...

開発時にソース内検索してrssやatomが無かった気がしたんだけど今見たら普通に埋め込まれてた（つらい）

f:id:sue445:20190815165516p:plain

*1: https://cloud.google.com/appengine/docs/standard/runtimes , https://cloud.google.com/appengine/docs/standard/go112/go-differences

動機

解説

circleci-bundle-update-prをGitHub Actionsで動かす方法

補足

circleci-bundle-update-prをGitHub Actionsで動かすメリット

circleci-bundle-update-prをGitHub Actionsで動かすデメリット

余談1

余談2

バージョンアップ時の注意点

日本語の関連記事

その他

前提

ベースになるジョブをincludeで別リポジトリから読み込むと便利

include導入前

include導入後

メリット

上記templateでやってること

Terraform実行専用のRunnerを作る

limit = 1 にする理由

メリット

1リポジトリ辺り20並列までジョブを並列実行できる

ジョブ実行時はアクセストークンが勝手に設定されている

マトリクステストがやりやすい

実際にGitHub Actionsに移行したプロダクト

zatsu_monitor

activerecord-compatible_legacy_migration

index_shotgun

デメリット

yamlのanchorが使えない

マトリクステストだとSlack通知がつらい

合わせて読みたい

リリースノート

Breaking changes

必要であればWhyを補足するためのContextを書く

起点となるURLを明記する

アプリケーションエラーやCIのビルドエラーであればバックトレースも（全部じゃないけど）書く

condo3

condo3について

モチベーション

技術的なこと

技術の選択理由

開発時に苦労したこと

名前の由来

地域.rbカレンダー

技術的なこと

メリット

8/15 16:50追記

`limit = 1` にする理由