頑張った…。
とっても軽微な修正だったけど、PR上げる時は本当に緊張しました。
備忘録というには余計な情報が色々書かれていますが、そこは御愛嬌ということで…。
何にPR上げたの？
AIアプリ開発プラットフォームの Dify にPRを作って上げました。
本記事はその時の備忘録になります。
何故PRを上げたのか
docker compose で設定した環境変数が効かない問題
Difyのサーバーを構築する機会があったため、 docker compose でとりあえず動かしてみるか〜と立ち上げてみました。
その際 docker-compose.yaml 内の環境変数でPostgreSQLのユーザーを変更しようとしたのですが、
設定して立ち上げてもPostgreSQLのユーザーが変わっていない…。
そもそも指定したユーザー自体がPostgreSQL内に作成されていなさそうだぞ…。
という事象に見舞われました。
利用できる環境変数が違う？
調べてみると、Difyの docker compose で使われているPostgreSQLのイメージはPostgreSQL公式が提供しているOfficial Imageを用いているようだったのですが、Difyで利用しようとしている変数名と、Official Imageで利用可能な変数名にどうやら差異があることがわかりました。
| 対象 | 変数名 |
|---|---|
| Dify | PG_USER |
| PostgreSQL | POSTGRES_USER |
PostgreSQLのOfficial Imageでユーザーを変更するのであれば、利用する変数名を PG_USER から POSTGRES_USER に修正する必要がありそうです。
…ただ、こういう事象って今までにも遭遇してきている人が結構いそうだし、既にどこかで言及されてるんじゃないかな？と、DifyのGitHubリポジトリを調べてみたところ、案の定既にこの問題に関するIssueとPRが存在していました。
Issue
PR
ただしどちらもクローズされてしまっていました。何故…。
既出Issueについて
既出Issueの内容は「環境変数に設定してもPostgreSQLのユーザーとパスワードが変わらない」というもので、
「新たに立ち上げ直せば設定されるよ」という回答でクローズされてしまっていました。
その後のやり取りで、「 POSTGRES_USER で環境変数を設定すればユーザーが変更できるよ」という形で、一応解決方法の記載はされている…といった状態になっていました。
既出PRについて
既出PRの方は、上記のIssueを受けて…というわけではなさそうでしたが、問題に気付いた方が修正対応のPRを上げた形でした。
しかし、適用されることなくクローズされてしまっています。
理由は docker-compose.yaml ファイルを直接編集していたためです。
Difyの docker-compose.yaml は、 .env.example と docker-compose-template.yaml を元に、 generate_docker_compose スクリプトを実行して生成されるものであるため、直接の編集は非推奨となっています。
既出PRでは、 docker-compose.yaml 内の PG_USER を直接 POSTGRES_USER に書き換えてしまっていたため、マージされずにクローズされてしまったようです。残念…。
どうするか… → PR上げてみようかな
そんなわけで、修正箇所は判明していたものの修正されていないという状態となっていました。
まあ docker-compose.yaml なので…そんなDifyの根幹の機能に関わるものでもないし、ちょっと調べれば解決方法はすぐわかるし…とそんな具合なのか、それ以降 PG_USER 関連のIssueやPRを上げている方はいませんでした。
じゃあどうしよう…別に手元の環境を整えるだけならローカルのファイルにちょっとした修正を加えればいいだけなんだよな…でもいい機会かもしれないし…気付いちゃったし…PR作って上げてみるか…軽微も軽微だし…ものは試しでいっちょやってみようかな…と重い腰を上げたわけです。
PR作って上げるだけならまあいいでしょう。「要らない！」と一蹴されてクローズされたらされたで…とあまり重く考えず、ひとまず作ってみることに。
どこを修正したのか
作ったPRを見てもらえるとわかる通り、とっても軽微な修正しかしていません。
| ファイル | 修正内容 |
|---|---|
docker/.env.example |
POSTGRES_USER=${DB_USERNAME} を追加 |
docker/docker-compose-template.yaml |
POSTGRES_USER: ${POSTGRES_USER:-postgres} を db コンテナの箇所に追加 |
docker/docker-compose.yaml |
上記の修正により、POSTGRES_USER: ${POSTGRES_USER:-${DB_USERNAME}} が追加(自動生成) |
docker/docker-compose.yaml |
上記の修正により、POSTGRES_USER: ${POSTGRES_USER:-postgres} が db コンテナの箇所に追加(自動生成) |
実際に変えたのは .env.example と docker-compose-template.yaml だけです。
docker-compose.yaml は上でも書いていますが generate_docker_compose の実行によって自動で適用された箇所となります。
意識したのは「既存の実装に影響を及ぼさないようにした」というところ。
PG_USER をそのまま POSTGRES_USER に置き換えるのも検討しましたし、恐らくそういった形で修正をしても特に問題は起きないだろう…とは思ったのですが、自分はDifyのオーナーでもPMでもメイン開発者でもないので、設計時の思想や実装がわかりません。
もしかしたら PG_USER も将来的に別の形で使われる変数になるかもしれないし…そのために予約しているのかも…という考えから、
PG_USER は削除せずに残したまま、新たに POSTGRES_USER を追加するだけの形としました。
余計なことをした結果、PRが無言でクローズされてしまった…みたいなことは避けたい思いもあり…。
修正したら、メッセージを書いてPRを上げるだけです。
DifyにはPRテンプレートがあるので、それに沿ってPRを書いていけばOKという親切設計なのですが、
英語なんて全然できない民なので、Summaryに何も書けないな…となり、参考に別のPRを見てみることにしました。
すると、Issueが上がっている場合は fixes: #issue_number としたり、
別で上がっているPRを元にした場合は follow-up: #pr_number とするらしいことがわかったため、
「これくらいなら英語できない民でも書けるし、最低限これ書いたら上げてしまっていいでしょう！」と、参考にした既出Issueと既出PRの番号をそれぞれ記載して上げてみました。
ここで普通に「上げてみました」とか書いているのですが、そんなサラッと上げられませんでした…。とにかく怖くて…。
自分のPRがノイズにならないかなとか、怒られないかなとか、本文の書き方本当にこれでいいのかなとか、そんなことを逡巡していたらﾎﾞﾀﾝﾎﾟﾁｰをするまでに30分とか1時間とか経っていました。
肝っ玉が小さいので仕方ないですね。
結果
一週間経過したくらいで無事にマージされた通知が届きました。ﾔｯﾀｰ!
DifyのGitHubリポジトリは非常に活況で、PRやIssueが毎日幾つも作られています。
そのため、マージされるにしろクローズされるにしろ結構時間掛かるのかなー、それなら気長に待とうかなーなんて思っていたのですが、「何か変化ないかな…」とちょくちょく上げたPRをチェックしていました。
気が気じゃなかった…は言い過ぎですが、かなり気になってしまいますね…。
ただ、マージ後にRevertされかけ(結果されませんでしたが)、更にフォローアップのPRが作られ、その結果色々考えて残した PG_USER はその姿を消しました。
どうせ消されるならあんまり気にせずに自分のPR内で消しちゃっても良かったかもなあ…なんて思いましたね。
また、自分の上げたPRに考慮漏れがあり、 docker/middleware.env.example の修正をしていなかったことが発覚しました。
これもフォローアップのPRで気付きました。やっぱり中の開発者は修正箇所ちゃんと把握しているんですね…。そして自分は見ていなさすぎか…。
影響範囲はちゃんと見ておこうねという話ですね。これは次に活かしたいです。
とはいえ無事にマージされて嬉しい限りでした。
そして数日後にこのPRを取り込んだ v1.5.0 が無事リリースされました。めでたい。
名前も載っている！嬉しすぎる…！
fix: add environment variable POSTGRES_USER by @ine1127 in #20786
なんか…達成感…そして感無量…。
docker compose の環境変数なんて、本当に軽微で機能には何ら影響もしない修正だけど、OSSに初めて貢献できたことはとても嬉しかったですね。
感想
今回は軽微なPRをOSSに上げた時の話を書いてみました。
やってみて思ったのは、まあ緊張しますね…ということ。軽微とはいえちゃんと緊張します。
自分の拙い修正とか言葉遣いが全世界に見られたりするというのを考えると震えますね…。
ただ、マージしてもらった時の喜びはひとしお。嬉しかった～…。
PRを作って上げてマージされることで「OSS」にも、OSSを通して「世界のどこかの誰か」にも貢献できたような、そんな実感が湧きました。
あとやっぱりOSSにPR作って上げるのってハードル高いように感じました。緊張します。なんか怖いですし。
慣れの問題はもしかしたらあるのかもしれません。仕事でもあんまりコードを書かない人間なので、それで緊張するなーっていうのはあったかもしれないですね。
でもいい経験になりました。
あとこれを経てすごく良かったのは、今までOSSにバグやちょっとおかしいなというところがあった場合に「スルーしよう」とか「手元の環境だけで動くようにすればいいや」となっていたところに、「PR作って上げる」という選択肢が自分の中にできたことですね。
今回は本当に軽微なものでしたが、今後も何か見つけたら積極的にPR作って上げるというのをやっていければいいなあと思いました。
最後に、改めてOSS作成者と関係者の皆様に感謝！ありがとうございました。
株式会社SKIYAKIのテックブログです。ファンクラブプラットフォームBitfanの開発・運用にまつわる知見や調べたことなどを発信します。主な技術スタックは Ruby on Rails / React / AWS / Swift / Kotlin などです。 recruit.skiyaki.com/
Discussion