nordize
(Nordize)
1
標準の(編集: 非開発版)Dockerインストレーションを /var/discourse に持っています。app.yml からリモートのGitHubリポジトリにリンクする代わりに、ローカルのプラグインディレクトリを使用してDiscourseにロードすることは可能ですか?もし可能であれば、その方法は?
機能するはずだと思った2つの方法を試しました。
-
GitHubから discourse-math を /var/discourse/plugins/discourse-math にクローンしました。launcher rebuild は discourse-math について何も言わず、Dockerマウントにも、GUIにも discourse-math はありませんでした。したがって、plugins フォルダは無視されていると推測しますか?
-
/var/discourse 外の別のディレクトリにクローンし、それを /var/discourse/plugins/discourse-math にシンボリックリンクすることも試しました…結果は同じでした。
-
GitHubリポジトリを /var/discourse-math.git にクローンし、app.yml を - git clone file:////var/discourse-math.git となるように編集しましたが、その後 launcher rebuild は fatal: '/var/discourse-math.git' appears not to be a git repository と不平を言いました…ランチャーはすでにDockerコンテナ内でこれを実行しているはずですか?手動で cd /tmp \u0026\u0026 git clone file:////var/discourse-math.git を実行すると、問題なく動作します。
plugins ディレクトリは Docker コンテナの外部にあり、マウントされています。
そのため、~/discourse 内から Discourse Docker を実行している場合は、ローカルの ~discourse/plugins にプラグインをクローンまたはシンボリックリンクすることができます。
nordize
(Nordize)
3
@merefield しかし、まさに私がすでにやったこと(私のメッセージを参照してください)ですが、うまくいきませんでした…何が足りないのでしょうか?
プラグインをリロードするには、Dockerコンテナを再起動する必要があります(適切なコマンドはこちら)。
nordize
(Nordize)
5
./launcher rebuild app でそれができるはずですよね?
それは本番環境、リモートインストール用です。
ローカル環境について話している場合は、私がリンクした開発用Dockerインストールを検討してください。
ローカルで本番インストールを実行するのは少し…奇妙です。
nordize
(Nordize)
7
はい、開発者向けインストールについては承知していましたが、標準のDockerインストール(つまり、開発者向けではないインストール)を使用しています。そのため、質問は依然として有効です。ローカルディレクトリからプラグインをサイドロードすることはできますか、それともapp.yml経由でのみGitHubからリモートでロードできますか?
追伸:「正しい」フローが開発者向けインストールを行い、そこで作業することであることは十分に承知しています。開発者向けインストールとセットアップの全プロセスを経る代わりに、プラグインをすばやく簡単に変更してテストする方法を求めていました。
承知しました。あなたの変わったセットアップに戸惑いました。
本番環境のインストールでは、コンテナ内にプラグインがクローンされるため、ローカルのプラグイン開発には適していません。そのワークフローでは、変更を GitHub にアップロードする必要があります。
そのセットアップは破棄して、主要な開発オプションである Docker または非 Docker のいずれかを使用することをお勧めします。
nordize
(Nordize)
9
念のため確認ですが、リモートのGitHubからクローンすることについてお話しされていますよね。GitHubのfile:///経由であっても、ローカルディレクトリからのクローンはできないということでしょうか? launcher.shはその時点でホストではなくコンテナ内で実行されており、ホストのマウントされたフォルダにクローンするのではなく、コンテナ内でGitHubからクローンするという意味でよろしいでしょうか。そうであれば、git clone file:///... を使用できます。
本番環境のインストールを、ローカルにマウントされたディレクトリにアクセスできるフランケンシュタインにしたい場合は、ビルドスクリプトを変更してそのアクセス権を与える必要があります。そのカスタマイズはご自身でサポートする必要があります。
個人的には、自分で仕事と脆弱性を作り出しているだけだと思います。
Docker開発環境のインストールは、効率的なローカルプラグイン開発のためのメンテナンスの少ないソリューションを提供するように設計されていますので、ぜひご検討ください。
nordize
(Nordize)
11
はい、承知しております。もちろん、おっしゃる通りです。プラグインのJavaScriptファイルでテストするための簡単な変更でした。コンテナ内のファイル(/var/www/discourse/public/assets/plugins/discourse-math-.js)を直接編集しましたが、何らかの理由で、ブラウザに変更が反映されません。ブラウザは古いファイルを見ており、キャッシュをクリアしても、おそらくプラグインのJSファイルが埋め込みNginxなどによってキャッシュされているためだと思われます(?)。
コンテナ内の現在のJSファイルを編集し、ブラウザで表示可能にするためのヒントをいただけると幸いです。
「短い手紙を書く時間がなかった」という状況に陥ってしまったかもしれません…開発環境の適切なセットアップを行う時間がなく、コンテナ内のJSファイルを変更してブラウザで変更を表示させるのがこんなに難しいとは思っていませんでした(DiscourseがプラグインJSファイルをどのようにキャッシュしてブラウザで変更を表示させるかについて、読む時間がほとんどありませんでした)などなど。
JSファイルのみであれば、テーマコンポーネントにデプロイできます。
テーマコンポーネントは、discourse_theme gem を介して HTTPS でアクセスできる限り、サイトにコピーできます。
ローカル環境をセットアップする必要はなく、既存のリモート本番サイトをその目的で使用することもできます。
Discourse Theme CLI (themes you build to help you build themes) - howto / developers - Discourse Meta を参照してください。
「いいね!」 1
nordize
(Nordize)
13
それは既存のプラグイン(すなわちイニシャライザー)のjsファイルで、これを改造したいのです。テーマコンポーネントでは役に立ちません(私の理解が間違っていなければ)。
テーマコンポーネントは最後に読み込まれるため、プラグインを上書きすると考えられます。
もう1つの良い方法は、プラグインをフォークし、ローカルでクローンして変更を加え、ローカルの dev インストールを使用してテストすることです。満足したら、フォークにコミットしてプッシュし、本番環境でフォークを使用します。
ただし、テーマコンポーネントソリューションには、親プラグインが進化するにつれて面倒になる可能性のあるフォークを維持する必要がないという利点があります。
nordize
(Nordize)
15
テーマコンポーネントが、こちらのようなファイルを変更する必要がある場合に役立つかどうかはわかりません…そのファイル(および他のファイル)は、私の理解では、マッパーなどを介して、ブラウザがロードするコンテナの /var/www/discourse/public/applets/plugins/discourse-math-<id>.js ファイルを生成します。後者のみを変更する必要がありますが、ブラウザには古いファイルが表示されたままです。サーバー側のキャッシュがあるかのようです。
ローカル開発環境のセットアップは時間と手間がかかりますが、すべてが失敗した場合は行うかもしれません。プラグインのJSを汚く変更するのがこれほど大変だとは思いませんでした。また、サーバー側のキャッシュがコンテナのNginxにある場合を除き、直接編集したものがブラウザに表示されない理由がまだ理解できません(JSなので理由がわかりません)。
いずれにせよ、今日これについて調べる時間は終わりました:(。とにかく助けてくれてありがとう!
「いいね!」 1
問題ありません。
達成しようとしていることの具体的な内容には立ち入れませんが、あるイニシャライザーが別のイニシャライザーの後に実行されるようにするには、この after: パラメータを使用します。例:
(クレジット @angus)
開発ツールはまさにこの目的のために進化しているので、可能であればそれを使用してください。開発用 Docker 環境のセットアップは、数時間ではなく数分で完了するはずであり、一度行えばその後はあらゆる目的に役立ちます。使い慣れているからといって、本番環境のインストールをローカルで使用しようとしないでください!
それは単にその目的には設定されていません。
「いいね!」 1
nordize
(Nordize)
17
馬鹿だと思われるかもしれませんが、デフォルトのポート3000を別のポートに変更するにはどうすればよいですか? d/boot-dev --init は、そのポートを別の目的で使用しているため失敗します。 -e UNICORN_PORT=4200 を試しました。見たガイドにはポートに関する記述がありません。 config/cloud/cloud66/files の thin.yml ファイルも無視されているようです。
Rubyサーバーポートは3000、Emberポートは4200です。両方のプロセスを実行する必要があります。ブラウザからは4200経由でサイトにアクセスします。開発用Dockerのインストールについては、開発用Dockerのトピックで話し合った方が良いですか?
nordize
(Nordize)
19
さて、d/boot_dev --init が失敗します (Error starting userland proxy: listen tcp 127.0.0.1:3000: bind: address already in use.)。後でさらに詳しく調べるかもしれません。お時間をいただきありがとうございます。これらのことがもっとよく文書化されていればよかったのですが。
そのようです。ポート3000で既にプロセスが実行されています。それを終了してください。
lsof -wni tcp:3000 でそのポートを使用しているプロセスを一覧表示できます。