تراجع ضحل في جلب git في discourse_docker

الدعم
1

مرحباً،

كسر تغيير حديث في docker_discourse إمكانية تحديد علامة (مثل v2.6.0) في قيمة version: ضمن ملف app.yml. وهذا مفيد لـ تثبيت إصدارات أقدم من discourse لأغراض الاختبار.

تظهر المشكلة على النحو التالي عند تحديد version: v2.6.0 باستخدام e2eb085714dfcf2aa0117b0f2fdf39b762b0e18d:

I, [2020-12-05T10:59:38.848743 #1]  INFO -- : > cd /var/www/discourse && git remote set-branches origin v2.6.0
I, [2020-12-05T10:59:38.852600 #1]  INFO -- : 
I, [2020-12-05T10:59:38.852639 #1]  INFO -- : > cd /var/www/discourse && git fetch --depth 1 origin v2.6.0
From https://github.com/discourse/discourse
 * tag                 v2.6.0     -> FETCH_HEAD
I, [2020-12-05T10:59:41.405163 #1]  INFO -- : 
I, [2020-12-05T10:59:41.405307 #1]  INFO -- : > cd /var/www/discourse && git checkout v2.6.0
error: pathspec 'v2.6.0' did not match any file(s) known to git
I, [2020-12-05T10:59:41.411796 #1]  INFO -- :

بدلاً من المخرجات المتوقعة عند استخدام التغيير السابق مباشرةً:

I, [2020-12-05T11:22:14.717910 #1]  INFO -- : > cd /var/www/discourse && git fetch origin v2.6.0
From https://github.com/discourse/discourse
 * tag                     v2.6.0     -> FETCH_HEAD
I, [2020-12-05T11:22:15.672616 #1]  INFO -- : 
I, [2020-12-05T11:22:15.672683 #1]  INFO -- : > cd /var/www/discourse && git checkout v2.6.0
Note: checking out 'v2.6.0'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at d6121249d3 Version bump to v2.6.0
3

لا أعتبر هذا خطأً بحد ذاته، لكننا نود تقديم بعض الإرشادات حول كيفية تثبيت الإصدارات القديمة من Discourse، حتى لو تطلب ذلك استخدام قالب أكثر تعقيدًا أو ما شابه.

@Falco يقوم بالتحقيق في الأمر.

4

أتفق على أن العمق يجب أن يكون قابلاً للتكوين، ربما عبر متغير بيئي، مع افتراض “shallow” كقيمة افتراضية؛ ولكن قابل للتكوين باستخدام متغير بيئي بسيط.

5

أعتقد أن المشكلة هنا هي أن الوسوم غير معروفة محليًا عند إجراء عملية الاسترجاع، مثل ما ورد في المسألة التالية (غير مرتبطة بـ Discourse):

يجب أن يؤدي تشغيل git fetch --all إلى حل المشكلة، لكنني لا أعرف إلى أي مدى قد يزيد ذلك من حجم الصورة (ما لم يتم مسح المراجع غير المستخدمة لاحقًا بواسطة تعليمات أخرى).

مع ذلك، أعتقد أن الأمر git clone --depth 1 https://github.com/discourse/discourse.git --branch=$version سيحل المشكلة، لأن الوسيطة branch تقبل كلاً من الفروع والوسوم، لكنني لم أجربها بعد ولا أعرف ما إذا كان هناك سبب لاستخدام الفرع الرئيسي (master) حاليًا في عملية الاستنساخ.

عند تنفيذ الأمر git clone --depth 1 https://github.com/discourse/discourse.git --branch=v2.6.0، يكون حجم المجلد بالكامل 212 ميجابايت، بينما يبلغ حجم مجلد .git بداخله 46 ميجابايت، لذا أعتقد أن هذا مقبول.

6

هذا يضاعف حجم المستودع :slightly_frowning_face:

المشكلة هي أنه وقت بناء الصورة لا أعرف الفرع الذي ستريده في المستقبل.

تم تغيير الإعداد الحالي لتقليل حجم الصورة، مما أدى إلى تقليل حجم الصورة المضغوطة بمقدار 250 ميجابايت (25%)، وهو فوز كبير. يعمل هذا بشكل جيد عند استخدام الفروع العادية مثل stable و beta أو tests-passed.

كحل بديل، إذا كنت ترغب في التبديل إلى وسم معين، يمكنك تطبيق ما يلي على ملف app.yml:

hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git
+    - exec:
+        cd: $home
+        cmd:
+          - git fetch --depth=1 origin tag v2.5.0 --no-tags
+          - git checkout v2.5.0

حل بديل آخر هو إضافة مفتاح base_image إلى المستوى الأعلى في ملف app.yml مع قيمة صورة أساسية أقدم. نظرًا لأننا لا نحاول حتى الحفاظ على توافق الصور الجديدة مع إمكانية تشغيل إصدارات أقدم من Discourse، فقد يكون هذا ضروريًا إذا كنت تعود إلى إصدارات قديمة جدًا.

7

أنت محق، في ذلك الوقت لا نعرف الإصدار. يبدو أن الصورة الأساسية تستخدم الإصدار الحالي + فرع tests-passed، على الرغم من أن الفرع سيحتوي على commit في الوقت الذي تم فيه بناء الصورة.

أليس من الممكن أن تكون الطريقة الحالية تؤدي إلى إعادة بناء أبطأ، حتى عند استخدام فرع tests-passed؟

فقط ضع في اعتبارك التعليمات التالية:

في الصورة الأساسية:

git clone --depth 1 https://github.com/discourse/discourse.git
cd discourse/
git remote set-branches --add origin tests-passed

في ملف web.template.yml

git reset --hard
git clean -f
git remote set-branches --add origin master
git pull
...
عند استدعاء `git pull`، **يتم سحب المستودع بالكامل**، وقد يستغرق عدة دقائق، لأنه تم إجراء استنساخ ضحل (shallow clone) فقط من قبل. يمكنك تجربة تشغيل التعليمات أعلاه محليًا ورؤية النتيجة. لا أقول إن وجود المستودع بالكامل في الصورة الأساسية أفضل، لكن الكود في `web.template.yml` سيعمل في كل إعادة بناء، حتى لو تمت إضافة إضافة (plugin) واحدة فقط أو تغيير إعداد في `app.yml`. ما أفعله عادةً في مشاريعي (غير discourse) هو إنشاء صورة جديدة لكل إصدار جديد، لكن قد لا يكون ذلك ممكنًا بالنسبة لك (بالنظر إلى الطريقة التي تتبعها حاليًا). ألم تلاحظ أي زيادة في وقت إعادة البناء؟ (أو ربما أن هذه الزيادة ليست كبيرة مقارنة بإجمالي وقت إعادة البناء في معظم الحالات)

تحديث

اختبرت الخطوات المذكورة أعلاه مرة أخرى وكانت سريعة. أعتقد أنني نفذت أمرًا آخر في المحاولة الأولى غيّر شجرة git، مما أدى في النهاية إلى محاولة سحب كل شيء عند تشغيل git pull.

8

هل أنت متأكد من ذلك؟

➜  discoursesmall git:(6a42acbf) docker run --rm -it discourse/base:2.0.20201125-2246
root@b481d11669ba:/# cd /var/www/discourse/
root@b481d11669ba:/var/www/discourse# du -sh .                                                     
774M    . 
root@b481d11669ba:/var/www/discourse# git pull
...
root@b481d11669ba:/var/www/discourse# du -sh .                                                                
778M    .
10

@lucasbasquerotto أنت محق في الإشارة إلى أن أمر git pull ليس ضروريًا تمامًا، وقد قمنا بإزالته هنا

يجب أن يسمح هذا للفروع الأخرى (أو الشوكات) بالتفاعل بسلاسة أكبر مع discourse_docker في المستقبل :slight_smile:

11

نعم، أرى أنه يقوم بجلب البيانات ثم يتحقق من الفرع الصحيح بعد السحب، لذا أعتقد أن أمر git pull غير ضروري (لم أجرب ذلك بعد).

بالنسبة للعلامات، يبدو أنني ما زلت بحاجة إلى جلب كل علامة بشكل منفصل، لكن يبدو ذلك ممكنًا. علاوة على ذلك، تُستخدم الفروع بشكل أكثر شيوعًا، لذا فإن العلامات ستكون مجرد حالة هامشية.

12

هل من الآمن افتراض أن خيار الإصدار في ملف التكوين standalone.yml لا تأثير له؟

13

لا يزال له تأثير، لكنه يمكن تعيينه للفروع فقط الآن.

14

أنا أحصل على نفس الخطأ. كنت أستخدم الإصدار 2.5.1.

عند ذلك، أحصل على الخطأ التالي:

I, [2020-12-31T11:50:24.701475 #1]  INFO -- : > cd /var/www/discourse && find /var/www/discourse ! -user discourse -exec chown discourse {} \+
chown: cannot dereference '/var/www/discourse/public/plugins/styleguide': No such file or directory

إعادة البناء لن تعمل. هل هناك أي مساعدة؟

15

جرب إضافة المفتاح المذكور واستخدام صورة أقدم من discourse/base - Docker Image

16

هذا لا يعمل لأنه يحدث بعد الكود الذي يفشل لأنه لا يمكنه استرجاع الإصدار. ما نجح هو إنشاء ملف version.template.yml بجانب web.template.yml بالمحتوى التالي:

params:
  home: /var/www/discourse

run:
  - exec:
      cd: $home
      hook: code
      cmd:
        - git fetch --tags

ثم تضمين هذا الملف في containers/app.yml، قبل web.template.yml كما يلي:

templates:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/version.template.yml"
  - "templates/web.template.yml"
17

لكي يعمل ذلك، لا يجب عليك استخدام مفتاح version على مستوى الأعلى في ملف app.yml الخاص بك، بل فقط هذا الكود الجديد. عند فعل ذلك، لن يفشل.

18

شكرًا لتوضيح ذلك: هذا هو الجزء الذي كنت أفتقده بالضبط. لأولئك الذين يشعرون بالحيرة بنفس الطريقة التي كنت أشعر بها، يمكن الحصول على إصدار مُعلَن من Discourse عن طريق:

  • التأكد من أن معلمة version غير مضبوطة في app.yml، على سبيل المثال:
    params:
  db_default_text_search_config: "pg_catalog.english"
  #  version: stable
  • إضافة كود للتحقق من الإصدار المطلوب في نهاية ملف app.yml، على سبيل المثال:
    hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git
+    - exec:
+        cd: $home
+        cmd:
+          - git fetch --depth=1 origin tag v2.5.0 --no-tags
+          - git checkout v2.5.0

عند تشغيل ./launcher rebuild app، يحدث ما يلي:

  • يتم التحقق من الإصدار الافتراضي version (أي الفرع test_passed).
  • يتم جلب وفعليًا التحقق من وسم v2.5.0، مما يستبدل الإصدار السابق فعليًا.