Lilly
13 مايو 2026، 6:49م
1
أحاول فهم كيفية التعامل مع بوت discourse-patch-triage الجديد عند تقديم طلبات سحب (PRs) من التفرع (fork) الخاص بنا، والأمر محير بعض الشيء، خاصة في محادثة ثلاثية الأطراف بيني وبين البوت ومراجع من الفريق. هل هناك طريقة صحيحة للقيام بذلك؟
لا أستطيع أن أطلب منه إصلاح الاقتراحات التي يقدمها على التفرع الخاص بي. في الوقت الحالي، أحاول معالجة ردوده حول اختبارات المواصفات (spec tests)، وأنا لست متأكدًا على الإطلاق مما إذا كنت أقوم بذلك بشكل صحيح — فأنا أفضل أن أطلب منه إصلاحها نظرًا لأن هذا يبدو خيارًا مقترحًا.
على سبيل المثال، أنا أصلح فشل اختبارات المواصفات على تفرعي الخاص لطلب السحب، لكن يبدو أن هناك بعض الاحتكاك بين ما أقوم به وما يريد البوت فعله:
main ← Lillinator:automation-recurring-month-fix
Ah this is from a fork, which patch-triage does not support writing to directly.… @patch-triage, how do I fix these tests?
```
Failures:
1) Recurring scheduling next pending automations with monthly frequency doesn't fail to schedule if the current time is within subsecond of the time component of start_date
Failure/Error: example_procsy.run
2023-11-01 07:30:00 UTC is not within 1 millisecond of 2023-11-05 07:30:00 UTC
# ./plugins/automation/spec/triggers/recurring_spec.rb:167:in 'block (4 levels) in <main>'
# ./spec/rails_helper.rb:756:in 'block (3 levels) in <top (required)>'
# /var/www/discourse/vendor/bundle/ruby/3.4.0/gems/timeout-0.6.1/lib/timeout.rb:296:in 'block in Timeout.timeout'
# /var/www/discourse/vendor/bundle/ruby/3.4.0/gems/timeout-0.6.1/lib/timeout.rb:304:in 'Timeout.timeout'
# ./spec/rails_helper.rb:746:in 'block (2 levels) in <top (required)>'
# ./spec/rails_helper.rb:703:in 'block (2 levels) in <top (required)>'
# /var/www/discourse/vendor/bundle/ruby/3.4.0/gems/webmock-3.26.2/lib/webmock/rspec.rb:39:in 'block (2 levels) in <top (required)>'
2) Recurring when trigger is called every_month creates the next iteration one month later
Failure/Error: example_procsy.run
2021-07-04 08:00:00 UTC is not within 1 minute of 2021-07-02 08:00:00 UTC
# ./plugins/automation/spec/triggers/recurring_spec.rb:408:in 'block (4 levels) in <main>'
# ./spec/rails_helper.rb:756:in 'block (3 levels) in <top (required)>'
# /var/www/discourse/vendor/bundle/ruby/3.4.0/gems/timeout-0.6.1/lib/timeout.rb:296:in 'block in Timeout.timeout'
# /var/www/discourse/vendor/bundle/ruby/3.4.0/gems/timeout-0.6.1/lib/timeout.rb:304:in 'Timeout.timeout'
# ./spec/rails_helper.rb:746:in 'block (2 levels) in <top (required)>'
# ./spec/rails_helper.rb:703:in 'block (2 levels) in <top (required)>'
# /var/www/discourse/vendor/bundle/ruby/3.4.0/gems/webmock-3.26.2/lib/webmock/rspec.rb:39:in 'block (2 levels) in <top (required)>'
Finished in 5 minutes 23 seconds (files took 0 seconds to load)
11658 examples, 2 failures, 4 pending, 1 error occurred outside of examples
Failed examples:
rspec ./plugins/automation/spec/triggers/recurring_spec.rb:149 # Recurring scheduling next pending automations with monthly frequency doesn't fail to schedule if the current time is within subsecond of the time component of start_date
rspec ./plugins/automation/spec/triggers/recurring_spec.rb:404 # Recurring when trigger is called every_month creates the next iteration one month later
Retrying failed examples and logging flaky tests...
Run options: include {locations: {"./plugins/automation/spec/triggers/recurring_spec.rb" => [149, 404]}}
Randomized with seed 8900
Recurring
scheduling next pending automations
with monthly frequency
doesn't fail to schedule if the current time is within subsecond of the time component of start_date (FAILED - 1)
when trigger is called
every_month
creates the next iteration one month later (FAILED - 2)
Failures:
1) Recurring scheduling next pending automations with monthly frequency doesn't fail to schedule if the current time is within subsecond of the time component of start_date
Failure/Error:
expect(pending_automations.first.execute_at).to eq_time(
Time.parse("2023-11-05 07:30:00 UTC"),
)
2023-11-01 07:30:00 UTC is not within 1 millisecond of 2023-11-05 07:30:00 UTC
# ./plugins/automation/spec/triggers/recurring_spec.rb:167:in 'block (4 levels) in <main>'
2) Recurring when trigger is called every_month creates the next iteration one month later
Failure/Error:
expect(pending_automation.execute_at).to be_within_one_minute_of(
Time.parse("2021-07-02 08:00:00 UTC"),
)
2021-07-04 08:00:00 UTC is not within 1 minute of 2021-07-02 08:00:00 UTC
# ./plugins/automation/spec/triggers/recurring_spec.rb:408:in 'block (4 levels) in <main>'
Finished in 7.53 seconds (files took 5.78 seconds to load)
2 examples, 2 failures
Failed examples:
rspec ./plugins/automation/spec/triggers/recurring_spec.rb:149 # Recurring scheduling next pending automations with monthly frequency doesn't fail to schedule if the current time is within subsecond of the time component of start_date
rspec ./plugins/automation/spec/triggers/recurring_spec.rb:404 # Recurring when trigger is called every_month creates the next iteration one month later
```
هل يجب أن أصلح هذه المشاكل في تفرعي الخاص، أم أن أترك للفريق أو للبوت إصلاحها بدلاً من ذلك؟
isaac
13 مايو 2026، 6:55م
2
شكرًا لك يا ليلي على هذا التبادل. هناك نقطتان:
للتفاعل مع البوت، يجب أن تعلق @patch-triage، ثم يمكنك استخدام اللغة الإنجليزية البسيطة لطلبك. تقتصر وظيفته حاليًا على المراجعة واقتراح التغييرات وإعادة أساس طلبك (PR) وإنشاء التزام جديد مع التغييرات المقترحة.
لن يقوم البوت بإجراء تغييرات على النسخ المشتقة (forks)، لكنه لا يزال قادرًا على المراجعة واقتراح التغييرات. لقد قمت مؤخرًا بإجراء تعديلات لتوضيح ذلك، لذا ستحتاج إلى التعامل مع أي تغييرات مقترحة بنفسك (كما فعلت).
إذا كنت ترغب في الاستفادة الكاملة من البوت، فإنني أقترح عليك إنشاء طلب سحب (PR) مباشرة إلى النواة الأساسية بدلاً من ذلك عبر نسختك المشتقة
أخبرني إذا كان ذلك يجيب على أسئلتك!
Lilly
13 مايو 2026، 7:10م
3
شكرًا لك، إسحاق، هذا يوضح الأمور. أنا معتاد فقط على عمل فورك للمستودعات لطلبات السحب، لكنني سأبدأ في تقديم طلبات السحب على الفروع الأساسية بدلاً من ذلك في حالات مثل هذه - يبدو أن بوت الفرز مفيد جدًا.
أيضًا، اختبارات المواصفات هي عذابي في البرمجة.
Lilly
13 مايو 2026، 8:15م
4
لا أعتقد أنني أستطيع فعل ذلك بعد الآن الآن بعد أن لم أعد من الموظفين
isaac
13 مايو 2026، 8:33م
5
آه… نعم. لا يزال بإمكانك الاستفادة من:
سأطرح موضوع السماح للشعب (Forks) بالحصول على صلاحية الكتابة على طلب السحب (PR) داخليًا.
