Pull Request に ラベルを付けたい話

これは SmartHR Advent Calendar 2020 - Qiita 7日目の記事です。 日々の開発時に Pull Request を作ったり、またそのレビューをしたり、レビューが終われば リリースしたりすると思います。 その際に、データパッチの実行を忘れないようにしたり、migration が含まれてるリリースになっているかを ひと目でわかりやすくするためのものを改て実装したので紹介です。

TL;DR

  • もともと 2017年につくった AWS lambda (nodejs 6.10) の実装があった
  • ↑の実行環境が EOL
  • ruby で実装し直したので紹介

やりたいこと

  • 特定のファイルが更新されたらその旨をラベルにつけたい
    • db/migrate/* のファイルが更新されたら db:migrate ラベルを付けたい
    • etc
  • base branch が特定の条件であればラベルをつけたい
    • 大きめの機能開発をする際に features/*** ブランチをきって開発しているので、そのさいに features/any-branch-name のラベルをつけたい

他の方法

実装的な課題と解決

  • GitHub REST API は Pull Request にふくまれる change files が300までしか取得できない
  • lambda の実装時は、 REST API を利用していたので、稀に対象の PR が大きいものになっていると change files が全て取得できない問題があった
  • GitHub GraphQL API では300以上取得できる
  • ruby 実装の際に、 change files は GraphQL API、 ラベルをつける実装は REST API の実装のハイブリッド構成にした
  • また、社内の複数のレポジトリでも動くようにかつ、それぞれの設定ができるようにする

実行時のフロー

  • Pull Request の Webhook を受け取る
  • payload の event の状態を見る
  • 対象の event であれば、 GraphQL API を call して、 change files を全て取得する
  • 設定に応じて、ファイルをチェックし、ラベルのリストを作る
  • REST API をつかって、 Pull Request にラベルを設定する

実行フローのサンプル

class Githubs::PrLabelerController < ApplicationController

  def create
    event = request.env['HTTP_X_GITHUB_EVENT']
    unless event == 'pull_request'
      msg = { message: 'event is not pull_request.' }
      render json: msg
      return
    end

    # webhook signature
    github_webhook_secret = ENV['GITHUB_WEBHOOK_SECRET']
    if github_webhook_secret
      http_x_hub_signature = request.env['HTTP_X_HUB_SIGNATURE']
      payload_body = request.body.read
      signature = GithubWebhookSignature.new(secret: github_webhook_secret,
                                             http_x_hub_signature: http_x_hub_signature,
                                             payload_body: payload_body)
      if signature.invalid?
        msg = { message: 'webhook signature is invalid.' }
        render json: msg
        return
      end
    end

    payload = JSON.parse(params['payload'])

    if payload['action'] == 'opened'
      pr_number = payload['number']
      full_repo = payload['repository']['full_name']
      owner, repo = full_repo.split('/')

      change_files = GithubQueryHelper.call(pr_number: pr_number, owner: owner, repo: repo)
      ::Rails.logger.info("💡 #{change_files}")

      # extract changes files.
      file_labels = config.labels[repo.to_sym][:files]
      targets = {}
      if file_labels.present?
        file_labels.each_key do |label|
          regex = Regexp.new(file_labels[label])
          targets[label.to_s] = change_files.select do |v|
            v unless v.match(regex).nil?
          end
        end
      end
      
      # add labels
      add_labels = targets.select { |_k, v| v.present? }.keys.uniq

      # extract base branch
      base_branch = payload['pull_request']['base']['ref']
      branch_labels = config.labels[repo.to_sym][:branch]
      if branch_labels.present?
        branch_labels.each_key do |label|
          regex = Regexp.new(branch_labels[label])
          next if base_branch.match(regex).nil?

          add_labels << if label.to_s == 'base-branch'
                          base_branch
                        else
                          label.to_s
                        end
        end
      end

      octokit = Octokit::Client.new(access_token: ENV['GITHUB_ACCESS_TOKEN'])

      octokit.add_labels_to_an_issue(full_repo, pr_number, add_labels) if add_labels.present?

      msg = { message: 'ok' }
    else
      msg = { message: 'action is not opened.' }
    end

    render json: msg
  end
end

GraphQL API をつかった change files 取得サンプル

class GithubQueryHelper
  attr_reader :pr_number, :owner, :repo, :github_client

  def self.call(pr_number:, owner:, repo:)
    new(pr_number: pr_number, owner: owner, repo: repo).call
  end

  def initialize(pr_number:, owner:, repo:)
    @pr_number = pr_number
    @owner = owner
    @repo = repo
    @github_client ||= GithubApi::V4::Client.new(ENV['GITHUB_ACCESS_TOKEN'])
  end

  def call
    retrieve_files_from_pr
  end

  private

  def retrieve_files_from_pr
    per_page = 100
    options = {
      pr_number: pr_number,
      per_page: per_page,
      owner: owner,
      repo: repo
    }

    files = []

    total = github_client.graphql(query: init_query(options))

    total_count = total['data']['repository']['pullRequest']['files']['totalCount']
    end_cursor = total['data']['repository']['pullRequest']['files']['pageInfo']['endCursor']
    page = (total_count / per_page.to_f).ceil

    files << total['data']['repository']['pullRequest']['files']['edges'][0]['node']['path']

    i = 0
    while i < page
      options[:endCursor] = end_cursor
      end_cursor, filelist = exec_query(list_query(options))
      files.concat(filelist)
      i += 1
    end

    files
  end

  def list_query(options)
    <<~QUERY
      {
        repository(owner: "#{options[:owner]}", name: "#{options[:repo]}") {
          pullRequest(number: #{options[:pr_number]}) {
            files(first: #{options[:per_page]}, after: "#{options[:endCursor]}") {
              pageInfo {
                endCursor
                startCursor
              }
              edges {
                node {
                  path
                }
              }
            }
          }
        }
      }
    QUERY
  end

  def init_query(options)
    <<~TOTAL_QUERY
      {
        repository(owner: "#{options[:owner]}", name: "#{options[:repo]}") {
          pullRequest(number: #{options[:pr_number]}) {
            files(first: 1) {
              totalCount
              pageInfo {
                endCursor
                startCursor
              }
              edges {
                node {
                  path
                }
              }
            }
          }
        }
      }
    TOTAL_QUERY
  end

  def exec_query(query)
    data = github_client.graphql(query: query)

    end_cursor = data['data']['repository']['pullRequest']['files']['pageInfo']['endCursor']

    files = []

    data['data']['repository']['pullRequest']['files']['edges'].each do |edge|
      files << edge['node']['path']
    end
    [end_cursor, files]
  end
end

おわり

おわり

ISUCON10 予選敗退した #isucon

今年も ISUCON の予選にでた。

今年は、一人で参加した。あと、個人スポンサーにもなってみた。


やったことメモ

  • mysql をapp の instance とは別 instance へ
  • app改善してみたけど、最終的にはほぼ revert
  • db の index追加
  • appのログ出力
  • unicornunix socket 通信化
  • nginx のログを ltsv にして alp でざっとログを確認
  • newrelic agent を突っ込んで把握できるように
  • unicorn を -E production で起動

最終的には、アプリの改善はほぼできず。。

f:id:tknzk:20200914223818p:plain


起きたこと

  • 103の instance をmysqlようにしていたら 17:30過ぎに突如 instance の応答が失われる..
  • しばらく放置して運営にチケット投げてみる
  • チケット投げたら、突如復旧...

感想

  • やっぱり、一人じゃ厳しいので来年はチームででるぞ..!
  • 運営のみなさま今年もありがとうございました!!

isucon.net

B2B SaaS (MTWA) でのアカウントモデルの検討事項

この記事は、SmartHR Advent Calendar 2019 の 9日目の記事です。

SmartHR に入社してから、その殆どの時間で、アカウント周りの改修やらなんやらを行っているのですが、 B2B SaaS におけるアカウントモデルの検討事項を洗い出してみました。

検討する上でのユースケース

  • B2B
    • 担当者が扱うアカウントで良い場合
  • B2E
    • 従業員のアカウントが必要な場合

一つのテナントに紐づくアカウントでよいか

  • サービス全体でアカウントを共有するモデル

    • GitHub
      • EMAIL などで一意のアカウントが発行される
      • org には招待などで紐づけ
  • テナントごとにアカウントを作成するモデル

    • Slack
      • テナントごとにアカウントが発行される
      • テナントの切り替え = アカウントの切り替え
      • テナントの切り替えが簡単にできるUIをつくるだけで良いかも
  • 複数のテナントにまたがってログインができる機能は必要か

    • サービスの特性によって、必要な場合もある

アカウントを作成するのは誰か

  • 招待の概念が必要か
    • サービスの特性による
      • 従業員も使うサービスであるならば、従業員アカウントを管理者権限のアカウントが招待をする必要があるかもしれない
      • もしくは、社員番号などと連動した従業員アカウントの発行などが必要かもしれない

従業員それぞれのアカウントが必要なのか

  • 従業員がサービスにアクセスする必要があるならば、必要
    • 勤怠管理システムなど

権限設定が必要か

  • 任意の権限を設定できる必要があるか
  • 従業員がアクセスできるサービスの場合は必須
    • 見えてはいけないものを見えないように

認証は独自でやるのか IdP と連携するのか

  • 認証基盤を運用するのは大変
    • できれば IdP と連携するものをリリース当初から持っておいたほうが楽
      • そもそも IdP に投げる仕組みにしてあるほうが好ましいかも
    • 退職したら、アクセスできないようにする必要があるかも

セッションの管理はテナントごとになっている必要があるか

  • 複数のテナントにまたがったアカウントがなければ不要かも
  • MTWA のアーキテクチャとしてテナントの切替方法がどの様になっているか
    • サブドメインベースでテナントがきりかわるのか
    • 同一ドメインで PATH にテナント情報が付与されているのか
    • Slack の web 版が最近、サブドメから PATH 方式に切り替わっていてなぜなのかが気になるところです。

おわりに

サービスの成長や、方向性などで、無限に考えることが多くなりがちですが、 つどつど見極めつつ、検討するのがいいかと思います。

SmartHR でのアカウント周りについて、悲喜こもごももあるのですが、 書けない話も多いので、気になる方は、どこかで直接あったときにでも。

ISUCON9 予選敗退した #isucon

今年も ISUCON の予選にでた。

今年は、去年のチームメンバーの都合が合わずに新規で、社内で募集してチームを作って参加した。
メンバーは @ykarakita@tak_wak_dev でチーム名は ウデムシlab 。
二人は初参加だったけど、事前練習をすることができずに、ぶっつけ本番となってしまった。


アプリの改善は二人に任せつつ、下回りをザクッと対応する方針で進めた。

やったことメモ

  • ruby 実装に変更
  • nginx のログを ltsv 化
  • alp に食わせて必要なタイミングで共有
  • nginx -> ruby 間を unixsocket に変更
  • mysql 用の instance に変更
  • mysql slow log の確認

アプリの改善の方は

という感じで、 N+1 を潰す作業に追われてしまった様子だった。

あと、途中で オフィスに誰か来たなと思ったら LINEからきた人だった


最終スコアは、 3910イスコイン で惨敗だった。。

f:id:tknzk:20190909001620p:plain


初参加の二人に ISUCON の楽しさをしってもらえたので、来年も、がんばるぞ..!
運営の皆様、ありがとうございました!

isucon.net

builderscon tokyo 2019 に行ってきた #builderscon

今年も Discover something new! ということで builderscon に行ってきた。

https://www.instagram.com/p/B1vfxTCj7NQ/ 今年も #builderscon の季節がきた

前夜祭

  • 技術の無駄遣いすごい
  • 残念なセッションがあったのは残念だった

1日目

  • B2B SaaS のテナント間のデータのやり取り難しそう
  • DB のバックアップ大事ですね 大事ですね
  • WebAuthn 取り入れる場合に UX やっぱりそうなりますよね
    • 一般に普及するまでどのくらいかかるんだろう
  • TracePoint マジ TracePoint
  • JIT すごい
  • Kyash さんすごい。胆力いりそう。Message Bus すごい

懇親会

  • 同じ眼鏡の人が3人あつまった! なぜ..

2日目

  • 式年遷宮を4年ごとに繰り返しているのすごい
  • 作り込みすぎないとかマネージドにふるとかの勘所
  • Elixir ちょっとさわってみよ
  • スーパーカミオカンデ、すごすぎて語彙失った..
  • Profile! Always measure first
  • RLS 検証してみたい
  • 時間を扱うの大変そう

見本市

まとめ

  • 知らないことを知れたので今年も良かった。
  • B2B SaaS のセッションが複数あって、MTWAの盛り上がりを感じた
    • また、知見の共有とかしてみたいなあ

終わり

  • 登壇された皆様、運営チームのみなさま、ありがとうございました!
  • また次回も参加するぞ!

builderscon.io

ISUCON8 予選敗退した #isucon

今年も ISUCON に出場した。

去年と同じチーム(ウデムシマニア) で出場できたので、今年は事前の練習などはせず、ぶっつけ本番で予選となった。 ISUCONを初期からみていた勢としては、どっかで観たことあるなあと感じる予選の問題だった (ISUCON2のアンサーだった模様)

チーム内の役割は去年と同様に、アプリ改善はチームメンバーに任せつつインフラ周りや db 周りをみた。 自分がやった内容としては下記な感じ

  • ruby 実装に変更
  • db を別インスタンスへ移動
  • mysql の slow query の抽出
  • reservations テーブルの非正規化
    • 初期データの調整
  • /etc/my.conf.d/server.conf の変更
  • redis 投入
  • 細かいクエリの削減 (投入できず)

初手で h2o じゃんとなってしまい、、ログ収集の手をそうそうに停めてしまったのが、今から考えると、それがベンチの分析がうまくできなかった要因だった。。 時間があるタイミングで、手に馴染んでる nginx などに入れ替えるべきだった。

去年は、途中でブレークスルーが起きてスコアがバキッと上がるポイントがあったが、 今年は、ずっとブレークスルーが起きず、スコアが停滞し続けてしまい、最後の1.5時間ぐらいで駆け込みでスコアが少し伸びただけであった。。。

get_events / get_event の処理が改善できず... ベストで 4,258 で 最後は 3,120 で終了で予選敗退となった...

おまけ

オフィスで3人で作業していたら、急にオフィスのドアが開いて、忘れ物を取りに来た同僚に写真を撮ってもらった

https://www.instagram.com/p/Bnyy-2shG9C/ ISUCON

おわり

今年も、力及ばず予選敗退になってしまった。。。来年こそは予選突破したい! 運営の皆様、ありがとうございました!

isucon.net

builderscon 2018 tokyo に行ってきた #builderscon

今年も Discover something new! ということで、前夜祭から行ってきた。

# 前夜祭

  • やっぱり闇の話はすごい...
  • ピカピカ光るなにかほしい!
  • ロボットボールって作れるんだ..!

# NAFUDA
https://www.instagram.com/p/BnY49cVh2kK/
とりいそぎ設定した #builderscon

# 1日目

  • envoy 便利そうだなあ
  • 謎ガジェットの原価...

# 2日目

  • Excelまじやばい
  • Excel便利すぎる...
  • 会社の同僚の purintai の登壇を見守りつつ楽しんだ

# おまけ
同僚と記念撮影した
https://www.instagram.com/p/BndQA6kBCyP/
builderscon.io#builderscon twitter/instagram:@hdeinc

# まとめ

  • 今年は、勤務先がスポンサーしたこともあって、同僚とワイワイ過ごせた
  • 失敗とか闇とかの話はぐっとくるものがある
  • NAFUDAハックするぞ!
  • 登壇されたみなさま、運営チームのみなさま、ありがとうございました!

builderscon.io