11

を実行するjekyll --serverと、サイト全体が再構築されます。十分な大きさのサイトでは、これには非常に長い時間がかかります。サイト全体の再生成を防ぐフラグを使用しても、--auto完了までの時間はかなり長くなります (私は 10 秒以上、一部の人は数分と報告されています)。これは、1 つのページを編集してプレビューする場合に不便です。その時間を短縮したいと考えています。

Jekyll がページを再構築するのに時間がかかる理由を判断する手段はありますか?

あるいは、Jekyll でより短い (より短い) フィードバック ループを可能にする編集ワークフローの推奨事項はありますか?

4

2 に答える 2

4

サイト全体の構築にかかる時間を解決することはできませんが、ドキュメントの下書きとレイアウトの変更を劇的にスピードアップする方法を思いつきました。これはすべて、編集のためにローカル マシンで作業し、運用サーバーに展開することを前提としています。プロセスが異なる場合、マイレージは異なる場合があります。

中核となるアイデアは、それぞれが同じ出力場所を指す複数の jekyll ソース ディレクトリを使用することです。私の場合は3本使います。投稿の下書きと編集用 (「_drafts」と呼ばれる)、レイアウト、デザイン、機能の変更用 (「_dev」と呼ばれる)、サイト全体のコンテンツを含む最後のもの (「_main」と呼ばれる) です。

最上位のディレクトリ構造は次のようになります。

./_drafts
./_dev
./_main
./html

各 jekyll ソースの _config.yml ファイルは、jekyll が生成した出力を 'html' ディレクトリにポイントするように次のようにセットアップされます。

destination: ../html

「_drafts」および「_dev」ディレクトリには、「_main」サイトのデザインと機能を模倣するために必要な最小限のファイルが含まれています。私はこれら 2 つのディレクトリですべての作業を行い、作業中のディレクトリで jekyll を実行します。私のローカル Web サーバーは、ローカル ドメイン (例: http://jekyll-test/) が「html」ディレクトリを参照するようにセットアップされているため、変更中に何が起こっているかを確認できます。

編集が終了したら、新しく更新されたファイルを「_dev」または「_drafts」から「_main」の対応する場所にコピーします。ファイルが配置されたら、'_main' で最後の jekyll を実行します。このアプローチでは、サイトを本番環境にデプロイする前に、長いサイト生成時間を 1 回待つだけで済みます。私はこのアプローチをしばらく使用してきましたが、大きな違いがあることがわかりました。

ワークフローを最適化する方法は他にもいくつかあります。

  • シンボリック リンクを使用して、'_drafts' と '_main' のデザインと機能を同期させます。

    Mac または Linux マシンを使用している場合は、シンボリック リンクを設定./_drafts/_config.ymlして参照先./main/_config.ymlを指定./_drafts/_layoutsし./main/_layoutsます (Windows にも同様の機能が存在する可能性がありますが、私はそれについて話すことができません)。何らかの理由で、jekyll はシンボリックにリンクされたいくつかのディレクトリでうまく動作しません。たとえば、私のインストールでは、シンボリック リンクとして機能しないルート レベルの「css」ディレクトリがあります。すべての場所に実際のコピーが必要です。

  • デプロイ スクリプトを作成します。

    デプロイの準備ができたら、jekyll を直接実行しません。「_main」ディレクトリで jekyll を呼び出し、出力を本番サーバーに rsync し、完了したら通知する小さなスクリプトを作成しました。これにより、jekyll で待機する必要がなくなるだけでなく、サイトのデプロイに必要な手順の数が減ります。

  • 追加のスクリプトとツールを構築します。

    '_dev' および '_drafts' ディレクトリからファイルをコピーすることは大したことではありませんが、自動化を追加するには最適な場所です。たとえば、'_config.yml' ファイルと '_layouts' および 'css' ディレクトリを '_dev' から '_drafts' と '_main' の両方に (必要に応じて) コピーするコマンド ライン スクリプトがあります。

    ドケットの別のツールは、投稿を「_drafts」から「_main」に移動するローカル Web アプリです。ファイルの移動を容易にし、作成と公開の摩擦を軽減するものは何でも良い.

  • LiveReload を使用する

    ローカルで実行するとjekyll --auto、ファイルの作業中に変更を自動的に生成するのに最適です。これに自然に付随するのはLiveReloadというアプリです。ローカルの「html」ディレクトリを監視し、コンテンツが変更されたときにブラウザの自動リロードをトリガーします。これにより、ブラウザー ウィンドウをテキスト エディターの横に置いておくことができ、ファイルを保存すると自動的に変更が行われるのを確認できます。時々少し不安定ですが、使用した後は、それなしでどのように暮らしていたのかわかりません.

于 2013-02-03T16:06:33.270 に答える
3

これは、Github の Jekyll の問題トラッカーで繰り返し取り上げられている問題です。残念ながら、それは目的の 1 つではありません。例えば：

「コンパイル」と「時間」という単語を検索するだけで、さらに多くの情報を見つけることができます。リンク切れの可能性があるので、見た目よりも少し難しいです。

また、LSI を使用している場合は、最新バージョンを使用してください。これに関連する修正により、はるかに高速になります。

あなたへの私の唯一のアドバイスは、これらすべての投稿が本当に必要かどうかを確認することです (わかっています、わかっています)。なぜなら、それがおそらく今、課題トラッカーから得られる唯一の答えだからです。誰も始めたくない。

PS: あなたの問題をイシュー トラッカーに投稿してください。不満を言う人が多ければ多いほど、修正される可能性が高くなります。

于 2013-02-03T12:15:07.573 に答える