Lilly
5월 13, 2026, 6:49오후
1
우리가 직접 포크에서 PR을 만들 때 새로운 discourse-patch-triage 봇과 어떻게 작업해야 하는지 파악하려고 하고 있는데, 팀 리뷰어와 셋이서 대화하는 상황에서 특히나 조금 혼란스럽습니다. 이 작업을 제대로 수행하는 방법이 있을까요?
내 포크에서 봇이 제안한 수정 사항을 적용하도록 지시할 수 없습니다. 현재 저는 스펙 테스트 관련 봇의 답변을 처리하고 있는데, 제가 올바르게 하고 있는지 전혀 확신이 서지 않습니다 - 이 옵션이 제안된 것 같으니, 봇에게 직접 수정하도록 지시하는 편이 나을 것 같습니다.
예를 들어, PR을 위해 내 포크에서 스펙 테스트 실패를 수정하고 있는데, 제가 하는 일과 봇이 원하는 일 사이에 어떤 마찰이 있는 것 같습니다:
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
5월 13, 2026, 6:55오후
2
그동안의 소통에 대해 lilly에게 감사드립니다. 몇 가지 말씀드릴 점이 있습니다.
봇과 상호작용하려면 @patch-triage를 댓글로 달고, 이후 요청사항은 평이한 영어로 작성하면 됩니다. 현재 봇의 기능은 리뷰, 변경 사항 제안, PR 리베이스, 그리고 제안된 변경 사항을 포함한 새 커밋 생성으로 제한되어 있습니다.
포크(fork)에서는 변경 사항을 커밋하지 않지만, 리뷰 및 변경 사항 제안은 가능합니다. 이 점을 명확히 하기 위해 최근 변경 사항을 적용했으므로, 제안된 변경 사항은 직접 처리하셔야 합니다(이미 그렇게 하셨습니다).
봇의 기능을 최대한 활용하시려면 포크를 통해 대신 코어(core)에 직접 PR을 생성하시는 것을 추천드립니다.
이 답변이 궁금증에 도움이 되었는지 알려주세요!
Lilly
5월 13, 2026, 7:10오후
3
아이스야, 고마워. 이제 명확해졌어. 나는 PR을 만들 때 리포지토리를 포크하는 방식에 너무 익숙해서 그렇지, 이런 경우에는 코어 브랜치에서 직접 PR을 시작하도록 할게 - 트리아지 봇이 꽤 유용한 것 같아.
그리고 스펙 테스트는 내 프로그래밍의 재앙이야.
Lilly
5월 13, 2026, 8:15오후
4
하지만 이제 스태프가 아니니까 더 이상 이걸 할 수 없을 것 같아
isaac
5월 13, 2026, 8:33오후
5
아… 네. 여전히 다음을 활용할 수 있습니다:
포크가 PR에 대한 쓰기 접근 권한을 가질 수 있도록 허용하는 문제를 내부적으로 제기하겠습니다.
isaac
5월 19, 2026, 4:35오후
8
@Lilly 업데이트가 완료되었고 이제 다음을 수행할 수 있습니다
@patch-triage에게 리뷰/리베이스/생성 또는 커밋 변경 사항을 요청할 수 있습니다포크에서도 모든 기능이 정상적으로 작동합니다
한 번 사용해 보고 문제가 발생하면 알려주세요
Lilly
5월 19, 2026, 10:19오후
9
제 포크에서 @patch-triage 봇 사용법을 대충 익혔는데, 원하는 변경 사항 처리와 함께 fix all을 지시했을 때 범위 밖의 다른 시간 구간의 코드를 대거 수정해버렸어요
