2019-10-20

「Gitify」を入れて GitHub 上での通知の見逃しを防止・軽減する

GitHub でチーム開発している時に以下のような見逃しがよく発生していました．

「○○さんにプルリクエストにコメントしたけど，返事が全然返って来ない．というかコメントしたの気づいてなさそう」
「あぁ！△△さんからの issue のコメント今気づいたわぁ」
Slack と GitHub を連携して通知するようにしてるんだけど，通知が流れてしまって気づかなかったわ．．．

Notification の画面やメールをチェックをすればわかりはしますが，開くのが面倒だなぁと思うことがあります．

そこで今回はそんな通知の見逃しをより防止・軽減する「Gitify」というデスクトップアプリのインストール方法と使い方をまとめていきます．

現在は(2019年)，Mac に対応しています．公式のウェブサイトには Mac OSX 対応となっておりますが macOS Mojave(10.14.6)で試した所，特に問題なく動作すること確認できました．

www.gitify.io

インストール方法
詰まったポイント
- いつまで経っても通知が来ない
- 「Authorizing OAuth Apps」の画面で認可できない

インストール方法

事前準備

Gitify をインストールする前に GitHub 側での設定が必要です．

ヘッダーの右にある自分のアイコン画像 → 「Settings」→ 「Personal settings」にある「Notifications」のリンクをクリックしましょう．

以下のように，通知の設定画面が表示されます．その中にある「Participating」と「Watching」にある「Web」にチェックを入れます．

f:id:bake0937:20191020132904p:plain

Gitify をダウンロードする

Gitify はウェブサイト・releases ページ・「Homebrew Cask」からダウンロードできます．詳しくは以下を見てみてください．

github.com

GitHub にログインする

Gitify を起動すると以下のような画面が表示されます．GitHub Enterprise にも対応しております．今回は GitHub.com の方を利用したいため「Login to GitHub」をクリックします．

f:id:bake0937:20191020140103p:plain

GitHub へのログイン画面が表示されるのでログインします． f:id:bake0937:20191020140230p:plain

「Authorizing OAuth Apps」の画面で， Gitify はどのような情報を利用するのかを確認し，問題が無ければ認可(「Authorize maosim」)のボタンをクリックします． f:id:bake0937:20191020141457p:plain

これでログインは完了です．この時点で GitHub 側で未読の通知が溜まっている場合は各リポジトリの通知が表示されます．

f:id:bake0937:20191020140443p:plain

通知内容を設定する

歯車⚙を押すと「Settings」が表示されます．ここで「Show notifications」を設定するとデスクトップに通知が来るようになります．

他にも設定項目があるので，好きな設定にしてみましょう．私は以下の設定です．

f:id:bake0937:20191020142218p:plain

使ってみる

これでインストールが完了しました．普段通りに issue やプルリクエストを作成してみましょう．

少し時間が経つと，以下のように自分のデスクトップ画面に通知が来ることが確認できます．

f:id:bake0937:20191020143045p:plain

Gitify を見てみると，以下のように通知の一覧が確認できます．

f:id:bake0937:20191020143526p:plain

これで GitHub での見逃しが防止・軽減され，チームでのコミュニケーションがやりやすくなりました．

詰まったポイント

この記事を見ての通り，インストールの作業自体はパット見問題無いのですが，私が遭遇した詰まったポイントをまとめていきます．もし似たようなところで詰まった場合は参考にしてみてください．

いつまで経っても通知が来ない

本記事の事前準備を確認してみてください．GitHub アカウントの通知設定はデフォルトで「Email」のみに設定されてます．

当時の私は，ここに気づくのに2ヶ月くらい掛かりました😅（「Web」にも設定したつもりが，実はされてなかった．．．という状態でした）

「Authorizing OAuth Apps」の画面で認可できない

以下のように「Authorizing OAuth Apps」の画面で認可のボタンをクリックできないことがあります．

f:id:bake0937:20191020150253p:plain

この件は公式リポジトリの issue でも報告されていました．どうやら Gitify 側に原因があるようです．

回避方法として「Authorizing OAuth Apps」の画面でデベロッパーツールを起動し，認可のボタンの要素にあるdisabled属性を削除すればクリックできるようになります．

詳しくは以下の issue を確認してみてください．

github.com

色々と詰まったポイントはありましたが，Gitify にはいつも助けられています 🙏

2019-10-16

Google Analytics にある記事へのリンクにアクセスすると「Not Found」になる場合の対応方法

Google Analytics

今月からこのブログにGoogle Analytics (以下，GA)を導入したのですが「行動 → 概要」画面にある記事ページへのリンクにアクセスすると「Not Found」になることが判明したため対応方法をまとめてみました．

方法はとても簡単でしたが，調べるのに意外と時間が掛かりました（ググり方が難しかった‥）．

f:id:bake0937:20191016213907p:plain

プロパティ設定を確認
他の設定項目も確認してみる

プロパティ設定を確認

「Not Found」になる記事のURLを確認したところ，不要な「/」（スラッシュ）が入っていました．
そのため，この「/」を消せば解決できそうであることがわかりました．
GAを導入した初期の頃の設定内容を確認したところ，プロパティ設定の「デフォルトのURL」でURLの末尾に「/」を入れていることが原因であることがわかりました．

f:id:bake0937:20191016173102p:plain

URLの末尾にある「/」を削除し，保存ボタンを押します．

f:id:bake0937:20191016172704p:plain

更新してから少し時間が経った後に記事へのリンクにアクセスすると正常に記事が表示されました．

f:id:bake0937:20191016214121p:plain

他の設定項目も確認してみる

今回はかなり初歩的なところでミスをしていました．
参考にした記事は以下になるのですが，まさに「後で後悔する」状態になっていました．プロパティやGoogle Search Consoleの設定など他に後悔をしていないかを確認してみようかと思います． primarytext.jp

こちらの書籍もオススメと聞いたため読んでみようと思います． book.mynavi.jp

2019-10-13

capistrano-releases-notificationでデプロイ周りのチーム内コミュニケーションが改善した話

Capistrano Slack GitHub octokit Ruby

capistrano-releases-notificationを導入したことでデプロイ周のチーム内コミュニケーションが改善されました。今回はその時の話を書いていきます。
試したRubyのバージョンは2.6.5、Capistranoのバージョンは3.10.1です。

f:id:bake0937:20191013144616p:plain

導入経緯
使い方
ちょっと一工夫
動作確認
- staging
- production
導入してみた結果
追記(設定内容がよりわかりやすい実装方法)

導入経緯

普段の業務でデプロイツールとしてCapistranoを使っているのですが、今のチームで以下の課題がありました。

誰がどの環境に何の内容でデプロイしたかはCapistranoを実行した人しかわからない
- revisions.logなどを見ればわかるが、わざわざサーバーにsshするのは手間
リリース報告が手動でSlackでコメントして連絡するため手間
staging環境やqa環境などを利用するときは台帳(誰がどの環境で何を検証しているかを記録する謎のスプレッドシート)に書いてチームメンバーに共有しているのだが、台帳のメンテを度々忘れてしまう

ということで、上記の課題を解決できる方法は何かないかを探してみた所、元同僚のkimromiさんがCapistranoでデプロイ時にSlackに通知をしてくれる便利なプラグイン(Gem)を公開していたことを思い出し、導入してみました。
また、このプラグインを導入することによってただSlack通知されるだけではなく、どのPullRequestでリリースしたかがわかるようになってさらに便利になりました✨。

kimromi.github.io

github.com

使い方

使い方については↑のkimromiさんの記事とリポジトリをご確認ください。
私なりに工夫した設定は以下に記載します。

ちょっと一工夫

ひとまず記事の内容を見て導入してみた結果、この時点でもだいぶ便利になったのですがチームメンバーから以下のフィードバッグを貰いました。

どの環境にもデプロイされたことはSlackに通知してほしい
staging(production以外)のSlack通知は以下の情報がほしい
- デプロイした人
- デプロイしたブランチ名
- デプロイしたソースコードのコミットのURL

ということで、以下のように修正をしました。

どの環境にもデプロイされたことは通知してほしいとのことのため各deploy/以下に設定してあるafter 'deploy:finishing', 'release:notify'を削除し、config/deploy.rbに設定することで共通化
デプロイした人の情報はgitコマンドを利用して表示できるように設定
productionとstaging以外の環境がある場合はelsifで設定していく

config/deploy.rb

# config valid for current version and patch releases of Capistrano
lock "~> 3.10.1"

set :application, "アプリケーション名を入れる"
set :repo_url, "git@github.com:GitHubアカウント名/リポジトリ名.git"

# slack webhook
set :slack_endpoint, 'https://hooks.slack.com'
# 実際に使う場合、この値は環境変数に入れた方が良さそう
set :slack_path, '/services/xxxxxxxxxx/xxxxxxxxxx/xxxxxxxxxx'

# 設定したいチャンネル名を設定
set :release_notify_channel, ['#general']

set :release_notify_title, '通知のタイトル名を入れる'

if fetch(:stage).to_s == 'production'
  # 設定したいメンション先を設定
  set :release_notify_mention, ['@channel']
  set :release_notify_message, (lambda {
    "#{fetch(:stage)}をリリースしたよ〜\n#{proc { `git config user.name`.chomp }.call}さん ありがとう〜 #{fetch(:release_notify_mention).join(' ')}"
  })
  set :release_notify_attachment, (lambda {
    pull_request = Octokit.pull(fetch(:github_repo), fetch(:pull_request_id))
    [
      pull_request.title,
      pull_request.html_url,
      '------------',
      pull_request.body[0, 200]
    ].join("\n")
  })
else
  set :release_notify_message, (lambda {
    "Deployed #{fetch(:branch)} to #{fetch(:stage)} \n commit: https://github.com/#{fetch(:github_repo)}/commit/#{proc { `git rev-parse #{fetch(:branch)}`.chomp }.call} \n by: #{proc { `git config user.name`.chomp }.call} #{fetch(:release_notify_mention).join(' ')}"
  })
  # production以外はプルリクエスト未作成の場合があり、空にしないと最新のプルリクエスト情報が表示され、混乱するため空にした
  set :release_notify_attachment, (-> {})
end

#デプロイ終了後に通知する設定
after 'deploy:finishing', 'release:notify'

動作確認

実際に実行する際はbundle exec cap 環境名 deployですが、これをやるとホントにデプロイしてしまうため、まずは--dry-runオプションをつけて実行し、Slackでどんな内容で通知されるかを確認してみましょう。

capistrano-releases-notificationはoctokit.rbを使ってプルリクエストの情報を取得します。
そのため実行後、途中でGitHub Personal Access Token?とターミナルでGitHubの個人アクセストークンを求められて処理が中断されるので事前に作成しておきましょう。

作成後、個人アクセストークンをターミナルに入力し、Enterを押すとデプロイ処理が再開されます。個人アクセストークンの作り方は以下を確認してみてください。
help.github.com 実行してみた所、以下のようにSlackに通知されました。

staging

$ bundle exec cap staging deploy --dry-run

f:id:bake0937:20191013144839p:plain

production

$ bundle exec cap production deploy --dry-run

f:id:bake0937:20191013144616p:plain

問題なさそうなら、導入したいリポジトリにcapistrano-releases-notificationを導入後、--dry-run無しでcapistranoを実行すればOKです。

導入してみた結果

導入経緯で挙がった課題は解消され、デプロイ周りの連絡はSlackを見ればわかる状態になったため、手間だったSlackでの連絡や謎のスプレッドシートのメンテが不要になりました。
とても便利です。

また、productionへのリリースは今までの場合、どのような内容でリリースしたのかを手動でSlackでコメントして報告していたのですが、プルリクエストの内容でSlack通知されるようになったことでだいぶ楽になりました。
(その分プルリクエストの内容をちゃんと書かないとですね)。

さらにproductionへのSlack通知に対して、導入前よりカジュアルに 👍や 🎉の絵文字リアクションがつくようになってチーム内の雰囲気も良くなった気がします🚀。
kimromiさんありがとうございました!!!

これからCapistranoの通知系のプラグインを入れる人にオススメです。

追記(設定内容がよりわかりやすい実装方法)

なんとkimromiさんからリプを頂いた 🙌

あっちなみにstageごとの設定の分岐をdeploy.rbに書いてもいいんですが、deploy.rbはデフォルト設定として書いて、config/deploy/production.rb とかに環境ごとの設定を書くとそっちで上書きされるのでおすすめです👍
— Hiromi Kimura (@kimromi) October 13, 2019

とのことのため、以下のように実装した方が各環境毎に設定内容が整理されてわかりやすいことがわかりました。

config/deploy.rbにデフォルト設定を実装

# config valid for current version and patch releases of Capistrano
lock "~> 3.10.1"

# このリポジトリを自分のリポジトリに作りたい場合は、GutHubにリポジトリを作成し、作成したリポジトリ名、リポジトリのURLに変更する
set :application, "test-capistrano-release-notification"
set :repo_url, "git@github.com:bake0937/test-capistrano-release-notification.git"

# slack webhook
set :slack_endpoint, 'https://hooks.slack.com'
set :slack_path, ENV['SLACK_PATH']

# 設定したいチャンネル名を設定
set :release_notify_channel, ['#general']

set :release_notify_title, 'test-capistrano-releases-notification'

set :release_notify_mention, ['@channel']

config/deploy/staging.rbに以下を追加

set :release_notify_message, (lambda {
  "Deployed #{fetch(:branch)} to #{fetch(:stage)} \n commit: https://github.com/#{fetch(:github_repo)}/commit/#{proc { `git rev-parse #{fetch(:branch)}`.chomp }.call} \n by: #{proc { `git config user.name`.chomp }.call} #{fetch(:release_notify_mention).join(' ')}"
})
# production以外はプルリクエスト未作成の場合があり、空にしないと最新のプルリクエスト情報が表示され、混乱するため
set :release_notify_attachment, (-> {})

#デプロイ終了後に通知する設定
after 'deploy:finishing', 'release:notify'

config/deploy/production.rbに以下を追加

set :release_notify_message, (lambda {
  "#{fetch(:stage)}をリリースしたよ〜\n#{proc { `git config user.name`.chomp }.call}さん ありがとう〜 #{fetch(:release_notify_mention).join(' ')}"
})
set :release_notify_attachment, (lambda {
  pull_request = Octokit.pull(fetch(:github_repo), fetch(:pull_request_id))
  [
    pull_request.title,
    pull_request.html_url,
    '------------',
    pull_request.body[0, 200]
  ].join("\n")
})

#デプロイ終了後に通知する設定
after 'deploy:finishing', 'release:notify'

config/deploy.rbにif文でまとめて実装するよりもわかりやすくなりました🙌🙌

2019-10-09

ブログにGitHub Contribution Graph(通称: 草)を置いてみた

GitHub はてなブログやってみた

f:id:bake0937:20191009074216p:plain ふとブログのコンテンツを色々充実させたいと思い、GitHub Contribution Graph を置いてみました。今回はその設定方法と置いてみて思ったことを書いていきます。

Grass-Graphで草の画像URLを生成
ブログのサイドバーに草を置く
プライベートリポジトリのContributionも反映したい時は...
ブログに草を置いてみて思ったこと
- ブログからGitHubへアクセスできて便利
- 自分の日々の草(Contribution)とより向き合うようになった

Grass-Graphで草の画像URLを生成

id:a-know さんのGrass-Graphというサービスで、自分のGitHubのContributionのグラフを表す画像URLを生成します。自分のGitHubのアカウントIDを入力するだけで生成できます。簡単にできてかなり驚きました。 grass-graph.moshimo.works blog.a-know.me 私の場合、以下のような画像URLを生成することができました。

<img src="https://grass-graph.moshimo.works/images/bake0937.png">

ブログのサイドバーに草を置く

方法は id:JunichiIto さんの記事を参考に、サイドバーにモジュールを追加することで草を置くことができました。ありがとうございました。

blog.jnito.com

プライベートリポジトリのContributionも反映したい時は...

「プライベートリポジトリの内容は見せられないけど、草は生やしてるんだぜ!」
っていうのを皆に見せたい場合は、以下のようにGitHubのプロフィールページにあるContribution settingsをクリックし、Private contributions にチェックを入れるとプライベートリポジトリのContributionも反映できます。 f:id:bake0937:20191009154607p:plain

これで自分のブログに草を生やすことができました。

ブログに草を置いてみて思ったこと

草を置いて数日経ちました。色々思ったことはこちらです。

ブログからGitHubへアクセスできて便利

ブログからGitHubへよくアクセスするので、そのリンクが出来たのはシンプルに便利だと思いました。

自分の日々の草(Contribution)とより向き合うようになった

GitHubの草が表示されるページはプロフィールのページなのですが、思い返すと以下のようにプロフィールページを見る機会が少なかったのかなぁと思いました。

普段は自分のリポジトリ一覧にアクセスする時にまずはプロフィールページに開いたりなど数秒しか見ていない
場合によってはリポジトリのURLをブックマークしていて、そもそもプロフィールページを見ない日がある

そして、FindyやLAPRASで見てみると「うわっ・・・私の草原、コンクリート過ぎ・・・?」と思って変に焦ったりとか...
GitHubの草の生え具合(Contribution)が全てではない(他にも色々なgitのホスティングサービスがありますし)のと生やせば良いってものでもないですが、この草の生え具合を見た時にどう思うのかを考えるきっかけが増えて良かったと思いました。
ちなみに、今の草の生え具合を自分で見てみたどう思ったかについてですが、「やべ、もっと草生やすのを通して色んな技術をキャッチアップしていくぞ!!」でした(^_^;)。
草も生やしながら、このブログのコンテンツの中身も充実させていきます。

2019-10-06

octokit.rbを使ってリポジトリのリリースを作ってみる

GitHub Ruby octokit GitHub API

最近、業務でGitHub APIを利用するためにoctokit.rbを使ったため、その時のメモを残しておきます。

octokit.rbとは?
octokit.rbを使ってリポジトリのリリースを作ってみる
実行してみる

octokit.rbとは?

GitHub APIに対応したRuby製のクライアントです。 Ruby以外だと.NET(octokit.net)やNode.js(octokit/rest.js)があります。詳しくは以下を参照。

github.com developer.github.com

octokit.rbを使ってリポジトリのリリースを作ってみる

それでは実際にoctokit.rbを使っていきましょう!!
今回作るサンプルのコードはここに公開しているため実装を確認したい場合は適宜チェックしてみてください。 github.com

ディレクトリ構成は以下のようになります。

octokit-rb-create-release-sample
├── .env
├── .gitignore
├── Gemfile
├── Gemfile.lock
└── app.rb

作業用のディレクトリを作っておきます。

$ mkdir octokit-rb-create-release-sample
$ cd octokit-rb-create-release-sample

.envにGitHubのパーソナルアクセストークンが入るため今回は.gitignoreを作成し、.envを除外しておきます。

# octokit-rb-create-release-sample/.gitignore
.env

1. `Gemfile`を作成

Gemfileにoctokitと環境変数を設定するdotenvを入れます。

# octokit-rb-create-release-sample/Gemfile
# frozen_string_literal: true

source "https://rubygems.org"

gem "octokit", "~> 4.0"
gem 'dotenv'

2. `app.rb`を作成

app.rbを以下のように作成する。
やっていることは、対象のリポジトリの最新のプルリクエストを取得し、そのプルリクエストに対してのリリースを作成する内容です。
リリースの詳細にはプルリクエストのタイトルとプルリクエストの番号を入れておくことで確認しやすいようにしました。

# octokit-rb-create-release-sample/app.rb
require 'octokit'
require 'dotenv'
Dotenv.load

client = Octokit::Client.new(access_token: ENV['GITHUB_PERSONAL_ACCESS_TOKEN'])

# 最新のプルリクエストを取得
pr = client.pull_requests(ENV['GITHUB_REPOSITORY'], state: 'closed', per_page: 1)[0]

tag_name = Time.now.strftime("%Y%m%d-%H%M%S%z")
pr_title = pr[:title]
merge_comment = "pull request: ##{pr[:number]}"

# リリースを作る
client.create_release(ENV['GITHUB_REPOSITORY'], tag_name, name: pr_title, body: merge_comment)

3. `.env`を作成

パーソナルアクセストークンとリポジトリをセットします。
リポジトリはリリースを作成したいリポジトリ名で設定します。
パーソナルアクセストークンの作り方がわからない場合は以下を確認。
help.github.com

# octokit-rb-create-release-sample/.env
GITHUB_PERSONAL_ACCESS_TOKEN = パーソナルアクセストークン
GITHUB_REPOSITORY = ユーザ名/リポジトリ名

実行してみる

これで出来上がったので、実際に実行してみます octokit-rb-create-release-sampleのディレクトリ直下で以下を実行

$ bundle install
$ ruby app.rb

すると、以下のように対象リポジトリのリリースページを見てみると、リリースが作成されていることがわかります。
プルリクエストの番号部分はリンクになっているため、クリックすればプルリクエストのページへ飛べるのは便利!!!
f:id:bake0937:20191006195055p:plain

こんな感じでoctokit.rbを使ってみました。
今回のはあくまでサンプル用で、実際にはCIでのデプロイが完了したらリリースを作成するなどの使い方にはなると思います。
今後はoctokit.rbとSlack APIを組み合わせてちょっとしたツールを何個か作っていこうと思います。
github.com

2019-10-02

GitHubでマージしたブランチを自動で削除する簡単な方法

GitHub

GitHubで開発する時、いつも通りプルリクエストを送ってapproveを貰ったらmasterにマージをしているのですが、その時にマージしたブランチを削除するのをたまに忘れたりします。特に忙しい時はDelete branchを押さずにブランチが残ったままになったりします。

f:id:bake0937:20191002121820p:plain

Automatically delete head branchesでマージしたブランチを自動で削除する
追記

`Automatically delete head branches`でマージしたブランチを自動で削除する

マージしたブランチを自動で削除するGitHub Appsがあるので導入するか、自分で作ってみるかを考えていたのですが GitHub社のセミナーに参加した際にGitHub側でブランチの削除ができることを知りました(ホントに知らなかったのでびっくりしました)
やり方は簡単で、https://github.com/アカウント名/リポジトリ名/settings にアクセスし、Automatically delete head branchesにチェックを入れたらOKです。
※設定するにはadmin権限が必要です

f:id:bake0937:20191002122436p:plain

これでマージしたブランチは自動で削除されるので、消し忘れが解消できますね。ちなみに、消したブランチはプルリクエスト上でRestore branchを押せば復活できるので安心です。

今回の内容と全然関係ないですが、「意図せずにボタンなどを押した状態」のことを北海道弁で「押ささる」ってよく言うことをふと思い出しました(ホントに全然関係ない)。

追記

公式のドキュメントがあることに気がついたため載せておきます。 help.github.com help.github.com

2019-07-02

GitHubで自分が作成・コメントしたIssueやプルリクエストを探す方法

GitHub 振り返り

振り返りなどをする時にGitHubで自分がどんなissueを作ったり、どんなコメントしていたっけ?と思って調べることがよくあり、度々検索バーで自分のユーザ名を入力して調べていた。
しかし、以下のように公式ドキュメントに調べる方法がちゃんと載ってあったことがわかったのでメモしておく。英語(こっちが基本的に最新) help.github.com 日本語(最近できたっぽい) help.github.com