こんにちは。
この新しい機能/機能性をEメールで使用する必要があります。
まだマージされていないため（いつかマージされると想定しています）、本番環境のDiscourseを実行し、レビュー中のPRを含めるための推奨される方法はありますか？
通常のアップデートでDiscourseを更新しないようにする必要があると思いますが、それはおそらくアプローチを単純化しすぎているでしょう。
他の人がこのシナリオでどのように作業しているかについてのガイダンスがあれば幸いです。
-ジェイク
まず、わかりません。
しかし、これは機能するかもしれません。
cd /var/discourse
./launcher enter app
cd /var/www/discourse
su - discourse -c 'git fetch origin pull/<pr_number>/head:<local_branch_name>'
su - discourse -c 'git switch <local_branch_name>'
sv restart unicorn
それが機能する場合、ビルド中にそれを行うように app.yml に追加できます。または、すぐにマージされるのを待つこともできます。
それが事態を悪化させる場合は、
./launcher destroy app;./launcher start app
を実行すると、最後にビルドしたイメージに戻すことができます。
「いいね！」 3
それは非常に役立ちます、ありがとうございます。理想的には、それがマージされるまで待ちたいのですが、これに慣れていないため、数日、数週間、または数か月かかるのかは明確ではありません。
重ねて感謝いたします。
このPRに対する批判ではありません（詳細には見ていませんが）、一般的にこれは良い習慣だとは思いません。
- このブランチに留まっている間、コアからのアップデートは一切受け取れません。セキュリティパッチも含まれません。
- ブランチの変更（マージされるまで開発コードとして扱わなければならない）によって不安定になる可能性があります。
- もし却下されたらどうしますか？
- テストすらまだ実行されていませんか？
CDCKの開発者レビューを活用し、レビュー＆マージを待つべきではありませんか？
「いいね！」 5
それは良いアドバイスです。
私が提案したものでは、実際に機能することを確認できる（または、その質問に答える仕様があるかもしれません）、あるいは承認されるまでしばらくの間しのぐことができるかもしれません。多くの人は、いずれにしてもアップグレードを数週間（または数ヶ月）待っています。
「いいね！」 2
@merefield ありがとうございます。マージされるまで待つということだと理解していますが、合っていますか？
同意します、それは素晴らしいアイデアです。しかし、その間、メールのバウンスを処理する必要があります。
繰り返しますが、プロセスにどれくらいの時間がかかるかわからないため、その知識なしでは、かなりの時間がかかると想定します。
何かニュアンスを見落としているのかもしれません…
数週間試してみても大丈夫だと思います。もし別のリリースがあれば、次のリリースに合わせてPRを更新するか、他の解決策を見つけるか判断できます。おそらく最も簡単なのは、プラグインで行うことでしょうか？
待ってください。なぜプラグインで行わないのですか？
それが通常の進め方です。プラグインで行い、PRに興味があるかどうか尋ねます。現時点では、これを望んでいるのは地球上であなただけのように思えます。コアに追加すると、誰かが無期限にそれを維持する必要が出てきます。それは些細なことではありません。
「いいね！」 3
プラグインとして実装されない理由がわかりません。
そうすれば、コアのインストールとは別にプラグインを簡単に進化させることができます。
プルリクエストがマージされたら（もしされたら）、プラグインを削除できます！
「いいね！」 1
非公開のセキュリティパッチについても、この問題を解決する必要があります。
リポジトリからブランチをマージする内部ツールのコードがあります。あなたにも同じアプローチをお勧めします。
以下のようなものが、execブロック（おそらくafter_codeフック内）で機能するはずです。
# パッチを取得してマージする
git merge REFERENCE --no-commit
bundle install # 必要であれば
pnpm install --frozen-lockfile # 必要であれば
「いいね！」 5
@merefield @pfaffman プラグインではないのは、私たちにとってそれが簡単ではないからです。プラグインを書いたことがありません。これを接続する方法について何か指示があれば、喜んで確認します！
また、netcoreを「望んでいる」のは私たちだけだとは言わないでしょう。それは地球上で最大のESPの1つであり、コアでサポートされている他の多くのESPよりもはるかに大きいです。それが優れているとか、ユーザーが他のものを望むかもしれないとは言いませんが、netcoreは非常に大きく、高く評価されているESPです。実際、以前はpepipostだったため、ここで多くの議論を見ることができます。
「いいね！」 2
デュアル戦略が適切だと感じます。
- まずプラグインとして構築し、公開する
- CDCKとPRを交渉/議論する
プラグインを構築できないことが、PRの十分な理由にはなりません。
サードパーティは引き続きあなたのプラグインを使用できます。
「いいね！」 5
@merefield すみません、プラグインのビルドがPR作成と関係があると思われる理由は何ですか？Netcore自身がPRを作成しました。
おっしゃっていることの詳細を見落としているのかもしれません。
「いいね！」 1
提案です。デプロイメントのタイミングに柔軟性が増します。依存関係が少ない方が良いと思いませんか？
「いいね！」 2
プラグインを作成できるからです。
彼らがあなたのPRを受け入れるかどうかはわかりません。私もわかりません。
ヒントです。チームの誰かがこのトピックに返信しましたが、「はい、すぐに取り込みます」とは言っていませんでした。代わりに、「コアに数ヶ月間受け入れられないPRがある場合、私たちはこうします」というアドバイスをくれました。
それらがあなたの選択肢のようです。
私の返信をそれほど深く読み取る必要はありません。
私はインフラ担当なので、開発チームの優先順位については何も知りません。私にとっては、コミットは👍🏼に見えますが、より経験豊富な目には異なる意見があるかもしれません。
しかし、この質問に答えることは、セルフホスティング者にとって一般的に役立つアドバイス/FAQになるとは思います。
私の意見では、プラグインはここでは重すぎるでしょう。
「いいね！」 2
Well, shows what I know.
And I keep forgetting just how big the staff is now and how segmented the teams must be. It seems like just yesterday that most everyone knew most everything (of course even then people had their niches), but that “yesterday” was eight years ago.
「いいね！」 5
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.