terraform-aws-providerへコントリビュートした
先日、terraform-aws-providerにコントリビュートし、大規模？OSSへのコントリビュート経験をGETしました。
マージされた改修は、v5.26.0にて無事リリースされました。
かなり嬉しかった出来事であり、これは是非記録に残しておきたいと感じましたので、久しぶりにZennに投稿しようと筆を取りました。
本記事では、私が terraform-aws-provider へコントリビュート達成するまでの経緯を簡単にまとめます。
issue 作成
今回は、自分が terraform-aws-provider を使用している中で発見したバグを issue として報告しました。
報告した内容としてはaws_quicksight_data_sourceの apply 時の意図しない挙動に関するものとなります。
既にデプロイ済みのaws_quicksight_data_sourceの argument に対する変更を加えたコードを apply した際に、Error: updating QuickSight Data Source (xxxxxxxxx/example-id): InvalidParameterValueException: DataSourceParameters field is incorrectly setが発生していました。
エラー文言から内部で Data Source のAPIを叩いている辺りに何らかの問題あることが分かり、該当箇所の実装を軽く確認し Terraform の書き方に誤りがあるわけではなく実装のバグであると判断し issue として報告しました。
改修作業
まずは環境構築から行いました。
terraform-aws-provider は開発者向けのドキュメントが非常に充実しており、ドキュメントの通りに作業することで特別詰まることなく環境構築を進めることができました。
コードの改修についてですが、PRのファイル差分はこちらです。
元々の実装はUpdateDataSource呼び出し時に、Terraform の記述に差分が生じている Attibution の値のみ入力構造体のフィールドとして送信するように実装されていました。
これにより値の入力が必須であるフィールドと対応する Attibution に差分が生じていない場合に、無効な入力であると判定され AWS API からエラーが返ってきていたようです。
差分が生じているかどうかに関わらず、Terraform で定義されている Attribution は入力構造体のフィールドとして送信するように改修し、想定通りの動作を得ることができました。
コードの改修に加えて、テストコードの追加、CHANGE_LOGの記載を行いました。
こちらについてもドキュメントを参考にしつつ、直近マージされたPRのコミットなども確認しながら作業を進めました。
PR作成
PRの作成についても特にコントリビュータ側が難しいことを考える必要はなく、PRテンプレートとドキュメントに従っていったという感じです。
PRマージの条件としてAWS のリソース操作を伴う受け入れテストがPASSしていることが求められるのですが、このテストの実行をメンテナ側(HashiCorp側?)に任せることもできるということに驚きました。
AWS 操作は料金が発生してしまう可能性もあるので、経済的理由がコントリビュートの妨げになることを防ぐというのがこの方針の意図のようです。
無事マージへ
ドキドキしながらPRを作成し待つこと約3ヶ月、InboxにPRマージクローズの通知が来た時はかなりテンションが上がりました。
約4000のissue、約400のPRがOpenしている状態のリポジトリであることを考えると、3ヶ月は妥当な期間なのかなと思っています。(メンテナの皆さん本当にお疲れ様です)
最後に
今回の経験の中での私の1番の学びはなんといっても、ドキュメントの手厚さを感じることができたことです。
各ページ、項目のスコープの切り分けが非常に明確であること、網羅性も高いこと、などなどお手本にしたい点が盛り沢山でありました。
これからもOSS活動を続けて、自分の血肉になるような経験をプライベートでも積み続けていきたいですね。
この記事が、terraform-aws-provider、その他のOSSへのコントリビュートに興味のある方の参考になれば幸いです。
Discussion