こんにちは。サイボウズ株式会社 生産性向上チームの平木場です。
僕たち生産性向上チームは毎週水曜日に Productivity Weekly という「1 週間の間に発見された開発者の生産性向上に関するネタを共有する会」を社内で開催しています。
本記事はその時のネタをまとめたものです。
2023-01-25 号から、基本的に隔週で連載することとしました。たまに単独でも投稿するかもしれません。
今週は 2024-02-14 単独号です。
今回が第 142 回目です。過去の記事はこちら。
news 📺
Deprecation notice: v1 and v2 of the artifact actions - The GitHub Blog
GitHub Actions の actions/upload-artifact および actions/download-artifact の v1 と v2 が 2024/06/30 に Deprecate となることが発表されました。
v4 ではパフォーマンスが大幅に向上しているので、これを機にアップグレードを検討してみてはいかがでしょうか[1]。
なお、GitHub Enterprise Server では該当せず、対応は不要だそうです。
本項の執筆者: @r4mimu
Copilot in GitHub Support is now available! - The GitHub Blog
GitHub Support において、GitHub 公式ドキュメントを学習した GitHub Copilot とやりとりできるようになりました（GA）[2]。
これまでは GitHub Support で問い合わせをする際、回答は人間（GitHub のサポートチーム）が行なっていましたが、今後は先に Copilot in Support に聞くことができます。回答者が人間の場合はどうしてもやり取りに時間がかかってしまいますが、Copilot in Support であれば即座に回答が得られるのが嬉しいですね。最終的に問題が解決したら良いですが、解決しなかった場合はそのままサポートチケットを発行できます。
もちろん相手は生成 AI なので、必ずしも正しい答えが得られるとは限らないことに注意です。
さっそく試してみました。
回答例
質問
GitHub Actions の variables を
${{ secrets.GITHUB_TOKEN }}の権限を使って更新することはできますか？
回答
GitHub Actions の variables を更新するためには、REST API を使用する必要があります。しかし、GITHUB_TOKEN を使用して variables を更新することはできません。これは、
GITHUB_TOKENが限定的な権限しか持っていないためです。variables を更新するためには、
admin:orgスコープを持つアクセストークンが必要です。このトークンは、GitHub Apps または個人のアクセストークンを介して取得できます。以下に、REST API を使用して organization variable を更新する例を示します：
＜省略＞
正しいですね！GITHUB_TOKEN では variables は更新できません。
しかしこの結果は organization variable の場合の話なので、その後も repository variable の場合はどうなるのかや、GitHub Apps の場合はどうなるのかを聞いてみました。
聞いた結果は先日公開した次の記事にまとめていますので、興味があればこちらもご覧ください。
GitHub Actions の権限周りはなかなか調べるのが面倒なので、Copilot in Support で気軽に素早く答えがわかるのは嬉しいですね。
ただ、触ってみていくつか気になった点があったので、次に挙げておきます。
- ページを移動すると内容が見られなくなってしまう
- Submit a Ticket をクリックするまでチケットは発行されないため
- チケット一覧にも残らない
- 良い回答が得られたらスクショ等で保存しておこう
- Submit a Ticket をクリックするまでチケットは発行されないため
- チャット中は変換確定時のエンターキー押下でチャットが送信されてしまう
- 日本語でチャットする際は質問内容を別途書いてから貼り付けるなどをした方が良さそう
- 「My problem is solved!」をクリックすると紙吹雪が舞うよ。解決したら押していこう
特にページを移動すると内容が見られなくなってしまうのは落とし穴感が強いです。使う際は覚えておきましょう。
Copilot in Support、なかなか便利な機能です。人に質問するよりハードルは低いし、日本語で質問できるのでどんどん使っていきたいですね。
本項の執筆者: @korosuke613
Dockerの設定を大きく省力化する「Docker Init」コマンドが正式リリース。DockerfileやCompose設定ファイルなど自動生成 － Publickey
Docker Desktop 4.18 から、docker init がベータで入っていましたが、それが Docker Desktop 4.27 で GA となりました。
docker init は実行して訊かれる質問に答えると Dockerfile や compose.yaml などを自動で生成してくれる Docker のサブコマンドです。
ちなみに私は OrbStack 1.4.3 を使っており、docker init は使えません...
今回は私物のマシンで docker init を試してみました。
Docker のサブコマンドはプラグイン形式になっているらしく、init のバージョンは次のものが入っていました。
$ docker init --version
Version: v1.0.0
Git commit: ######
使いたい言語、そのバージョン、使用するパッケージマネージャー、使用するポートなどを訊かれ、答え終わると .dockerignore, Dockerfile, compose.yaml, README.Docker.md を生成してくれました。
なお、対応している言語には限りがあり、もしリストに無い場合は「Don't see something you need? Let us know!」を選択すると Google Form にリクエストを送信するようお願いが表示されます。
サクッと Docker まわりのテンプレートを引っ張ってくることができるので、プロジェクトの初動で少し楽になりますね。
本項の執筆者: @defaultcf
know-how 🎓
GitHubのMerge Queueとは何か？それと、認識しておきたいこと - Mitsuyuki.Shiiba
GitHub の Merge Queue とは何かという記事です。
どういう状況でなぜ Merge Queue が嬉しいのかを順序立てて丁寧に説明してくれています。また、Merge Queue を使う上で気にしておくべきこと、気をつけておくべきことも書かれており、Merge Queue 戦略を考える上で参考になります。
個人的には github.ref、github.sha、github.base_ref、github.head_ref がそれぞれのトリガーでどう変わるかをなんとなくでしかわかってなかったため、整理してくれていて勉強になりました。
Merge Queue は非常に強力な機能ですが、上手く使うのがなかなか難しいものでもあるため、いろんな記事や事例を参考にしつつ戦略を考えたいですね。
本項の執筆者: @korosuke613
Testing HashiCorp Terraform
Terraform plan や validate は問題無く実行できたのに、terraform apply で失敗したことはありませんか？私は何度もあります...
この記事では、テストピラミッドを示しながら、ユニットテストから順に Terraform でのテストの書き方を教えてくれています。
次のように例を示しながら、説明がされています。
- ユニットテスト
- 例えば、組込み関数を使って variable を加工し local 変数を作るような処理があった際に、入力と出力が期待通りであるかをテストする[3]
- run ブロックと assert を使ってテストできる
-
command = planで plan 時だけに走らせる
- コントラクトテスト
- 例えば resource で期待していない変数が来ないかをテストする
- variable ブロックと validation を使ってテストできる
- plan で実行される
- インテグレーションテスト
- 例えば apply 時にローカルにファイルが生成されるとして、それがきちんと存在するかテストする
- run ブロックと assert を使ってテストできる
- apply 時に実行される
- エンドツーエンドテスト
- 例えば apply 後にリソースが正常に動作していることを確かめる
- check ブロックを使ってテストできる
- apply 時に実行される
またユニットテストとコントラクトテストは plan 時に実行されるので、こちらを重点的に書いておくことで apply まで行く前にテストで落とすことができ、時間の節約にもなる旨が書かれています。
私は check ブロックの存在をよく理解していなかったので、この記事でその有用性をよく知りました。
また Terraform のテストでテストピラミッドを意識するということもなかったので、今後はこの記事を参考にテストを書いてみようかと思います。
本項の執筆者: @defaultcf
デプロイ頻度やリードタイムの正確な計測にこだわらなくていい（前提はあるが） - mtx2s’s blog
スクラムのようなイテレーティブな開発プロセスにおける、デプロイ頻度やリードタイムの計測と活用についての考察記事です。
結論としては、実測値を使うまでもなく、チームの誰もが知っているデプロイ頻度とリードタイム(ここでは、イテレーティブであるという前提を置いているので 1 スプリントなど)を用いれば十分と述べています。
そもそも改善したい対象はメトリクスではなくフローであるということを具体例や図を用いて立ち返っており非常に分かりやすかったです。
さらに、フローを改善する戦略として、「フローを速くする」ことと「フローの数を増やす」という 2 つの具体的なアプローチまで紹介してくれていて、実践的で非常に参考になりました。
Four Keys のような指標の計測に基づいて何かをする際は、メトリクスを良くすることを目的としてしまうミスが起こりがちです。定期的にこの記事を読み返して、改善の目的を見失わないようにしたいですね。
本項の執筆者: @r4mimu
あとがき
はい。ハッピーバレンタイン号でした。僕はなんとか今年チョコをいただくことができました（本命ではない）。ハッピーですね。
サイボウズの生産性向上チームでは社内エンジニアの開発生産性を上げるための活動を行なっています。そんな生産性向上チームが気になる方は下のリンクをクリック！
-
平木場注）なお、upload-artifact@v4 および download-artifact@v4 については、以前の Productivity Weekly 内で @Kesin11 さんが紹介してくれています。そちらもご参照ください -> actions/artifacts@v4アツい、CIの話題多め、おまけあり｜Productivity Weekly(2023-12-20号) ↩︎
-
それまでは一部の GitHub Enterprise ユーザがクローズドで使えたようです。今回一般提供が始まったことで、GitHub Free ユーザも触れるようになりました。 ↩︎
-
記事内では EC2 インスタンスの DNS 名から IP アドレスを抜き出す処理が例で出されていた。 ↩︎
Discussion