😄

terraform-provider-aws に初コントリビュートしました

2024/07/16に公開

先日 terraform-provider-aws に初コントリビュートしました。これ程大規模な OSS にコントリビュートできたのは初めての経験だったので、コントリビュートした背景と PR 作成からマージされるまでの軌跡を記載しようと思います。

https://github.com/hashicorp/terraform-provider-aws/pull/37898

aws_cloudformation_stack_set_instanceresource の機能不足を見つける

terraform で CloudFormation StackSet を管理したくなりました。また、アカウント ID を指定して特定のアカウントに対してのみリソースをプロビジョニングしたくなりました。ドキュメントを調べると、どのアカウントにリソースをプロビジョニングするかは aws_cloudformation_stack_set_instanceresource で制御していると分かったのですが、プロビジョニング対象が OU にしか対応しておらずアカウント ID に対応していないことが分かりました。
これに関しては既に issue があり、対応 PR も出されていました。

https://github.com/hashicorp/terraform-provider-aws/issues/33914

https://github.com/hashicorp/terraform-provider-aws/pull/26935

しかし、PR コメントのやり取りを見ると Update の動作でバグがあるようで2年近くマージされていない状況でした。バグ報告に対する PR 作成者の反応も無かったので、この PR の修正を待つよりは自分でバグ修正してしまおうと思い、対応に着手しました。

Contributor Guide を読み込む

terraform-provider-aws には Contributor Guide が用意されており、コントリビュートにおける手順や注意事項が事細かに記載されているので読み込みました。

https://hashicorp.github.io/terraform-provider-aws/

開発環境の整備

ローカルで開発するための手順が Contributor Guide に記載されているのでこれを参考に開発環境を整備しました。

https://hashicorp.github.io/terraform-provider-aws/development-environment/

修正作業

deployment_targetsに未対応の引数を追加する

こちらは既に出ている PR の内容を踏襲して対応しました。具体的には deployment_targets 引数が受け付ける要素が元々 organizational_unit_ids にしか対応していなかったので、その他の対応している要素も追加しました。対応する要素は aws-sdk-go-v2 の構造体で確認できます。

https://pkg.go.dev/github.com/aws/aws-sdk-go@v1.54.19/service/cloudformation#DeploymentTargets

引数更新時のバグに向き合う

バグの内容としては一度 apply してリソースを作成した後に、deployment_targets 引数の要素を変更して再度 apply しても変更が反映されないというものでした。実装を確認すると deployment_targets 引数の要素が変更されると UpdateStackInstances メソッドが呼び出されることが分かりました。このメソッドはその名の通り、UpdateStackInstances API を実行します。そのため、テスト用の AWS アカウントを用意して、StackSet を作成後に CLI 経由で UpdateStackInstances API を実行して動作を確認してみました。その結果、一度 StackSet を作成した後に UpdateStackInstances API でdeployment_targets 引数に変更後の OU やアカウント ID を指定しても更新されなかったり、エラーになることが分かりました。そのため、UpdateStackInstances を利用して deployment_targets を更新することは不可能と判断し、リソースを recreate する方針としました。特定の引数に変更が入った場合にリソースを recreate させる場合は Schema 構造体の ForceNew フィールドを true にします。

テストコード修正

上記の修正内容に沿ってテストコードを修正します。

テスト用 AWS アカウントを使った受け入れテストを実行する

何かしら実装を修正する PR を出す場合は受け入れテストを実行してテストが通ることを確認する必要があります。ここで言う受け入れテストとは実際に AWS アカウントに対してリソースを作成して想定した設定になっているかをテストします。詳細は Contributor Guide に記載があります。

https://hashicorp.github.io/terraform-provider-aws/running-and-writing-acceptance-tests/

ドキュメント修正

修正した内容に沿って、ドキュメントの修正と Changelog の 追加を行います。

PR を作成

ここまでで PR 作成の準備が整ったので PR を作成します。実際に作成した PR が以下になります。

https://github.com/hashicorp/terraform-provider-aws/pull/37898

PR 作成時のお作法や注意点は Contributor Guide に記載があります。また、他の PR も参考になるので見てみるのをおすすめします。

https://hashicorp.github.io/terraform-provider-aws/raising-a-pull-request/

メンテナによるマージを待つ

PR を出したらメンテナのレビュを待ちます。terraform-provider-aws は大規模な OSS のため、優先度に沿った順番でレビュされます。優先度付けのルールは Contributor Guide に記載があります。

https://hashicorp.github.io/terraform-provider-aws/prioritization/

今回の issue が数年前から報告されており、リアクションもある程度付いていたこともあってか PR を ready for review にしてから1ヶ月程でマージされて v5.58.0 でリリースされました。

https://github.com/hashicorp/terraform-provider-aws/releases/tag/v5.58.0

まとめ

terraform-provider-aws に初コントリビュートした経験を記載しました。これほど大規模な OSS へのコントリビュートは初めてだったので、とても良い経験になりました。前々から OSS へのコントリビュートをしてみたいと思っていたのですが、高いハードルを感じていて取り組めていませんでした。しかし、実際に取り組んでみると理解や実装が大変ではありつつも自分でも貢献できるものがあるんだなと実感できて良かったです。今回の経験を機にさらに OSS コントリビュート活動をやっていきたい思いました。

Discussion