JAWS-UG CDK 支部 #1 〜初回拡大版〜 はじめてのプルリク - BLEA 編 2022/06/01 watany 1

自己紹介 watany(渡邉 洋平） Twitter：@_watany 所属：NTT テクノクロス デジタルツイン事業部 APN アドバンスドコンサルティングパートナー 2022 APN ALL AWS Certifications Engineers 2

1. きっかけ 2. しくじりながらのプルリク 3. はじめての Contribute へ 3

CDK Confernece 楽しかったですね CDK Conference でも登壇しました ログミーさんで紹介いただき感謝！ AWS Solutions Constructs で システム作成は楽になるのか？ 実装・設計・非機能設計から見 る、活用のメリット https://logmi.jp/tech/articles /326653 そんな中、CDK JAWS の開催が決定 勢いで LT に飛び込む 当初予定（Service Catalog）とは 異なる点、申し訳ございません 4

LT の準備中 (元々の)発表テーマの大枠は考えて、調 査・検証だ！ そんな中 IAM Policy の面白そうな情報が 2021/4/1 AWSConfigRole -> AWS_ConfigRole が推奨。 ※この Blog がわかりやすい AWSConfigRole は非推奨な ので、AWS_ConfigRole に変 更しましょう https://blog.serverworks.co.j p/AWS_ConfigRole 5

もしかして 登壇テーマに BLEA を絡める予定だった BLEA：AWS CDK で定義されるベースライン用テン プレート AWS SA さん主導のプロジェクト ふと、該当しそうな base-standalone を覗いてみる usecases/base-standalone/lib/blea-config- stack.ts ”AWSConfigRole” のままだ！ ここで思い出す CDK Conference の記憶 ”気になる記載を見つけたら…それがコントリビュート チャンス！” 注：勝手な解釈です。 6

気になるポイント BLEA はプルリクを受け付けてるのか。 ”BLEA は GitHub にオープンソースとして公開しています。” https://aws.amazon.com/jp/blogs/news/announcing-baseline-environment-on-aws/ CONTRIBUTING.md はある。 AWS JAPAN の SA 主導のプロダクト。大人だし空気読むべきか。。。 まあダメでも Reject されるだけだし。。 OSS の Contribute したことない。 CONTRIBUTING.md を読む感じ、そこまで難しくなさそう Git は普通に使ってるし、何とかなるだろう ※この慢心が後々問題になります 7

はじめよう、プルリク。 8

1. きっかけ 2. しくじりながらのプルリク 3. はじめての Contribute へ 9

CONTRIBUTING.md を読もう 読んで理解した内容（私訳） i. GitHub の右上のボタンから Fork ii. 必要なソースを変更 GitPod も興味あるが今回は Cloud9 を開発環境に。 iii. ローカルでテストを確認 iv. コミットメッセージは明確に "fixed."とかで済まさない v. プルリクエスト。自動 CI がこけたら何と かする。 という訳で Let’s Try！ 10

1 通らない Build 1. fork & clone 2. fix & commit origin upstream local main main main commit 時になぜか落ちる？？？？ 11

原因と対策 エラーメッセージを読むと git secrets の戻り値が空。 つまり awslabs/git-secrets を install しよう おさらい：git-secrets commits, commit messages をスキャンして、git repo に残したくない Secrets の追加を防ぐツール 起動したて Cloud9 に導入漏れ BLEA の README_ja.md に書いてたよ！ 右図は抜粋 振り返り： 「ほーん、テストして cdk synth 通ればいけるやろ」 日本語ドキュメントが整備されているので、きちんと読 む。 12

2．突然閉まるプルリク 1. レビュー待ち。ここも実はプルリク出せるのでは 2. Wow! さっき main ブランチで直してたじゃん。まずは切り戻して...... 3. 閉じる Pull Request 13

どうして Main ブランチでプルリクし、該当リモートブランチの Commit を取り消したのが原因 fork 運用でブランチを切ったつもりになっていた Review 中に Close しなくて良かった そもそもフローの理解が曖昧だったのも遠因。 GitHub 公式の標準の手順を見よう プロジェクトに貢献する https://docs.github.com/ja/get-started/quickstart/contributing-to-projects 14

3. どこの馬の骨か 無事にプルリク完了！ビルドも通ったが以下のコメントを頂く。 Changes look like good to merge, but git author information in commits is incorrect. You may fix and force-push it to record your contribution in our repo. ざっくり翻訳： 君の Author おかしくない？ 再現図 よその人以前に、人で無さそうなアカウント 15

修正 Remote Branch へ Push 済 Commit の取り消し方法をググりながら何とか解決 以下で治ったけどベストプラクティスは不明 git rebase -i <コミットハッシュ> git commit --amend --reset-author git rebase --continue git push -f 16

1. きっかけ 2. しくじりながらのプルリク 3. はじめての Contribute へ 17

まとめ 無事に Merge！ Old Enough!な、しくじり記録 いかがでしたか？ 俺みたいになるな OSS の Contribute に興味はあるが心配になった人は、私と一緒に学びましょう プロジェクトに貢献する(再掲) https://docs.github.com/ja/get-started/quickstart/contributing-to-projects AWS CDK にコントリビュートするための具体的な方法 https://speakerdeck.com/tomoki10/how-to-aws-cdk-contribute 18

Appendix. そもそも BLEA に PR 出すのはどうなのか 明らかな bug fix、最新化追従は筋が悪くなさそう。 feature request はケースバイケースか BLEA はあくまで”Baseline”。恐らく”セキュリティもの全部入り”の思想ではない CDK 利用促進に向けた教材の側面も感じられる。 といいつつ Baseline かは微妙なラインの PR を Review いただいています。 いつもありがとうございます。 ”当たり前品質”を守りつつ、OSS には積極的に貢献していきましょう！ 19