GitHub

最近は小さなチームのリーダーとしてチーム運営をしており、GitHub Projects を何年かぶりに使っています。 GitHub Projects は以前からありましたが、2022/07/27 に完全リニューアルし、GA (Generally Available) となりました。 Planning next to your code - GitHub Projects is now generally available | The GitHub Blog 最近の使い方 こんな前提です。 現在は自分含めた 3 人のチーム コア開発っぽいリポジトリと、案件ベースのリポジトリ合わせて 10 個くらいある 1 つの機能をチームで開発することはなく、それぞれが別々の開発をしている 出来るだけレビューを通した PR をマージするように、合意はしている そんな GitHub Projects を再現したものがこちらです。Issue/PR が少ないのはご愛嬌。😅 @masutaka’s trial project 各 view の使い方 Board いわゆるカンバンとして使います。 -status:Idea というフィルターのとおり、Idea カラム（後述）は非表示にしています。 Inbox や Backlog などのカラムには、短いながらも的確な Description を書いたつもりです。例えば In Progress の「１人１つまで」だとか。 Schedule 期間を決めた主要 Issue や、期日が決まった Issue のスケジュールは、ここで確認できます。...

昨日、職場の同僚から教えてもらった、昨日公開されたこちらの本を読みました。 GitHubセキュリティ Organization運用のベストプラクティス 著者は @tmknom さん。[2019-05-07-1] に読んだ『Pragmatic Terraform on AWS』改め『実践Terraform 』の著者でもあります。 今の会社は 2014 年から GitHub を使っています。当初は全部分かりまっせ！という設定ボリュームでしたが、時を経てものすごくてんこ盛りになり、把握しきれない設定項目も増えてきました。 本書によって、それらの棚卸しが出来た気がします。 本自体のボリュームは大きくないので、流し読みすることも出来ますし、適度に GiHub Docs へのリンクになっているため、ガッツリ読むことも出来ます。 いたく感動したため、少額ながらサポートさせて頂きました。(^^) 欲張りすぎずにコツコツ改善していくことが大事だと、自分をリセット出来た気がします。

@kyanny さんの記事を自分なりに整理してみる。 ずっと「マージした後にメインブランチを production デプロイする」というワークフローだと勘違いしていた。 昔は「マージ後にデプロイ」だったが、いつの頃からか「マージ前にデプロイ」に変わったらしい。 どこかでそんな話は聞いていたけど、実際のところはどうなんだろう？と以前から疑問だった。やっぱりそうだったか。 現在の GitHub flow というか、GiHub の公式ガイドにそのものズバリ書いてあったのね。灯台下暗し…。 Understanding the GitHub flow · GitHub Guides “>” を数回クリックし、“Deploy” に進むと書いてある。 With GitHub, you can deploy from a branch for final testing in production before merging to main. main ブランチにマージする前に、最後の確認をするために本番環境にデプロイする。 If your branch causes issues, you can roll it back by deploying the existing main branch into production. もし問題が発生したら、main ブランチを本番環境にデプロイすることでロールバック出来る。 main ブランチの protection rule は “Require branches to be up to date before merging” を有効にしているのかな。いずれにせよ、main ブランチの commit 全部入りのブランチをデプロイしているはず。...

追記(2019-09-23): ⚠️ この記事の GitHub Actions は HCL 記法を使う古い方法です。現在は YAML 記法に変わりました。参考にしないで下さい。 先日 [2019-02-03-1] 作った GitHub Action のリポジトリページにこんな表示が出てました。 https://github.com/masutaka/github-actions-all-in-one-project こちらのドキュメント によると、リポジトリの Release ページ から公開できるとのこと。 全部グリーンになるように、Icon や Color などを直しました 。あとは普通にリリース。 あっさりとリリースできました！ https://github.com/marketplace/actions/all-in-one-project Marketplace の目立つところに表示！ されていたのですが、ちょうど週末 Marketplace がリニューアルしたようで、最後のページ に移動されていました。まあいいか…。 現在は https://github.com/masutaka/github-actions-all-in-one-project にアクセスすると、こんなメッセージが表示されています。ここの “View on Marketplace” から Marketplace の当該ページに飛ばされて、インストール出来る流れになっているようです。 とは言え、結構大味な流れなので、README.md を読んで導入したほうが良いと思います。[2019-02-03-1] もどうぞ。 追記(2019-02-12): GitHub Action の beta に申し込んでないと、上の Marketplace のページは全部見られないことを知りました。びっくり。https://github.com/features/actions から申し込めます。

追記(2019-09-23): ⚠️ この記事の GitHub Actions は HCL 記法を使う古い方法です。現在は YAML 記法に変わりました。参考にしないで下さい。 Issue や Pullrequest を作ったら、GitHub Project に自動追加なんてことができそうですね。 と [2019-01-28-1] に書いたので作ってみました。 この GitHub Action を使ったサンプルリポジトリが https://github.com/masutaka/sandbox-github-actions です。 Issue や PR を作ると GitHub Actions Trial part2 Project の To do または In progress カラムに自動的に追加されます。Fork 先からの PR でも同様です。Actions タブ で確認できますが、私以外は見られないのかな？ 設定方法は簡単で、.github/main.workflow に以下を追加するだけです（GitHub Actions はまだ beta 版なので、このページ から Sign up しておく必要はあります）。 PROJECT_URL と INITIAL_COLUMN_NAME は必須です。GITHUB_TOKEN はリポジトリに紐付いた token が自動的に使われます。詳しくはドキュメント をどうぞ。 Issue や PR がクローズされると Done カラムに、リオープンされると In progress カラムに移動します。これは GitHub Projects の Automation を使っています。...

追記(2019-09-23): ⚠️ この記事の GitHub Actions は HCL 記法を使う古い方法です。現在は YAML 記法に変わりました。参考にしないで下さい。 このブログの CI には割高なので、CircleCI あたりに乗り換える予定です。 と [2019-01-27-1] で書いたばかりですが、舌の根も乾かぬうちに GitHub Actions に移行してみました。 料金はさておき、たまたまクラスメソッドさんの記事 を見て移行出来そうだったことと、GitHub Actions は一度素振りしてみたかったからです。 GitHub Actions とは CircleCI の Workflows と非常に良く似た機能で、Pipeline を組んで CI を実行することが出来ます。 現在はまだベータです。https://github.com/features/actions からリクエストすれば使えます。複数 Action 同時実行とか凝ったことはできないようです。時間がかかりすぎる Action も避けたほうが良いかも。 Action は自分で作ることも出来ますし、以下のような公開 Action を使うことも出来るようです。 https://github.com/actions https://github.com/hashicorp/terraform-github-actions 日本語記事: GitHub Actions： みなさんが開発し、GitHubで実行 - The GitHub Blog - Japan Heroku CI よりもハマりどころはありますが、作り方はとてもシンプルです。 .github/main.workflow を作り、workflow と action を定義する 各 action に紐付いた Dockerfile を作る、または参照する 今回の実装 ファイル構成と実装はこんな感じです。...

さて、では通知をどうやって読むか？だが、原点にかえって GitHub の Notifications ページで頑張ってみたい。 私も何年も GitHub の Notifications ページをメインにしている。mention には絶対気づくし、周辺の情報もきちんと取捨選択が出来ていると思う。 GitHub の Notifications ページ Notifications の良いところは、イシューや Pull Request の件名が一覧表示されるので、件名で仕分けできそうな点だ。 そうなんですよね。実はだいぶ使いやすいです。 まずは https://github.com/notifications を訪れて Participating をクリックし、自分宛ての mention を読む。初めから Participating を訪れても良いかもしれない。 その後に Unread をクリック。自分のチームや興味あるリポジトリの通知は、ブラウザのタブで開いて全部読む。その他のリポジトリの通知はタイトルやユーザだけ見て興味あれば別タブで表示、なければ Mark as read。リポジトリ単位で Mark as read することも多い。 Watch リポジトリはしっかりメンテナンス そういう意味では、Watch リポジトリはしっかりメンテナンスしている。会社のリポジトリは 80% くらいは Watch して、通知が多すぎるやつとかは Unwatch している。 ただ、GitHub 公式だと https://github.com/watching で Unwatch しか出来ない。 仕方がないので、以前 GitHub Organization Watcher を作った。これは所属 Organization 単位でまとめて Unwatch/Watch/Ignore 出来るやつ。作りこんでなくてダサいけど、結構便利。 これでだいぶ捗った。 Trailer.app リアルタイムな通知は Trailer.app でゆるく受け取っている。あくまで通知メイン。...

こちらのブログではアナウンスしてなかったので。 v4.0.0 のリリースノートになります。 https://github.com/masutaka/github-nippou/releases/tag/v4.0.0 その後 v4.0.1 も出しました。 https://github.com/masutaka/github-nippou/releases/tag/v4.0.1 体感として速くなったことと、Homebrew のエコシステムに乗れたことが、 自分としてもメリットに感じています。 リファクタリングしないと…。

helm-github-stars.el という便利な Emacs Lisp ツールがあります。 「自分がつけた GitHub の Star」や「自分または Organization 所有の リポジトリ」等を Helm interface で操作できます。 「Star 付けたリポジトリがあったけど、なんて名前だったかなー」 なんて時に、素早く検索してブラウザで開けたりします。便利です。 課題 helm-github-stars.el は便利なのですが、キャッシュファイル （~/.emacs.d/hgs-cache）を作る hgs/generate-cache-file() は 同期処理関数です。Emacs built-in の url-retrieve-synchronously() を使っています。 うっかり M-x helm-github-stars すると、数十秒待たされます。辛いです。 ※ helm-github-stars-refetch-time を設定に基づき、 M-x helm-github-stars のタイミングでキャッシュファイルが更新されます。 そういうわけで、最近は当該キーバインドをコメントアウトしている状態 でした。 つい先日の木曜日。重い腰を上げて、非同期処理版の hgs/generate-cache-file() を作ろうとしました。でも、Star と Repo 両方の API を呼ぶ必要があり、なかなかに複雑です。コーディングが進 みません。 そんな中見つけたのが async.el でした。 async.el 今回使ったのは、async.el に含まれる async-start() です。 async-start START-FUNC FINISH-FUNC START-FUNC は子プロセスの Emacs で実行される FINISH-FUNC は現在の Emacs で実行される 上記のとおり、このライブラリはなんと Emacs の子プロセスとして、も...

v3.0.0 から出力フォーマットをカスタマイズ出来るようになりました。 @ryz310 に大感謝です！ リリースノートは以下をどうぞ。 https://github.com/masutaka/github-nippou/releases/tag/v3.0.0 新しいサブコマンド init を実行すると、デフォルト設定 から新しい Gist を作り、その後はその設定が参照されます。 参考までに私の設定はこちら です。subject を h3 から h4 に変えている のと、GitHub ユーザ名をリンクにしています。 副作用として v2 と同じフォーマットでは出力できなくなりました。 ご不便をおかけしたらすみません。 他の機能としては以下になります。 ・新しいサブコマンド open-settings 前述の Gist URL をデフォルトブラウザで開きます。設定していなければ、 デフォルトの GitHub URL を開きます。 ・Docker サポート 依存 Gem が増えてきたので、Dockerize してみました。ラッパースクリ プト docker-github-nippou を介して使うと良いです。ただし、Launchy を使う関係で、サブコマンド open-settings は使えません。