롤업 절차
배경
Rust 프로젝트에는 모든 풀 리퀘스트가 기본 브랜치에 푸시되기 전에 병합 후 테스트를 거쳐야 한다는 정책이 있습니다. PR 수가 늘어날수록 이 방식은 확장성이 떨어질 수 있습니다. 현재 Rust의 CI 소요 시간이 약 3.5시간으로 길다는 점을 고려하면 더욱 그렇습니다.
그래서 롤업이 등장합니다! 규모가 작거나, 성능에 민감하지 않거나, 플랫폼에 종속되지 않는 변경 사항은 bors의 rollup 명령으로 표시합니다(@bors r+ rollup은 PR을 승인하면서 롤업으로 표시하고, @bors rollup은 이미 승인된 PR을 표시하며, @bors rollup-는 롤업 표시를 해제합니다). ’롤업 수행’이란 이러한 변경 사항을 하나의 PR로 모아 한꺼번에 병합하는 것을 의미합니다. 롤업 명령은 always, maybe, iffy, never의 네 가지 값을 받습니다. 이러한 각 상태가 무엇을 의미하는지에 대한 안내는 리뷰 정책의 롤업 섹션을 참고하십시오.
롤업 PR 목록은 Rust의 Bors 큐에서 확인할 수 있습니다. 롤업 PR은 ‘approved’ 큐의 맨 아래에 ‘rollup’ 우선순위로 나열되며, 이는 큐에서 앞에 있는 모든 항목이 병합되기 전까지는 단독으로 병합되지 않는다는 의미입니다.
롤업 만들기
-
Bors 큐의 인터페이스에서 풀 리퀘스트를 선택한 다음 “Create rollup” 버튼을 사용해 롤업 풀 리퀘스트를 만드십시오. (공정성에 관한 문구는 무시해도 됩니다.) 중요 사항: 롤업 섹션의 리뷰 정책에 따라
rollup=always,rollup=maybe,rollup=iffy로 표시된 PR을 추가 대상으로 고려하십시오. 무엇을 포함할지 결정할 때, 특히rollup=maybe및rollup=iffyPR에 대해서는 각별히 주의하십시오. 위험을 감수하다가 회귀(버그 또는 성능 저하)를 겪는 일은 최대한 피해야 합니다. 또한 기여자들이 rollup=never 태그를 달아야 하는데도 잊어버리는 경우가 많다는 점을 고려하여, 롤업 태그가 명시적으로 달리지 않은 PR은 각별히 주의하십시오. -
풀 리퀘스트 스레드에서 다음 명령을 실행하십시오.
@bors r+ p=5 -
롤업이 실패하면 rust-log-analyzer가 제공하는 로그를 사용해 실패 원인을 특정 PR로 좁힌 다음
@bors r-로 해당 PR의 승인을 취소하십시오. 그런 다음 롤업 PR을 닫고, 문제가 된 PR을 제외한 채 1.부터 다시 시작하여 롤업을 새로 만드십시오. 롤업 PR 본문에는 기존 PR(r-된 PR 제외)로 롤업 UI를 자동으로 채워 주는 링크가 있습니다. 자세한 내용은 실패한 롤업을 참고하십시오. -
롤업이 성공하면 다음 롤업으로 넘어갈 수 있습니다(가끔씩
rollup=neverPR도 진행되도록 하십시오).
풀 리퀘스트 선택하기
큐는 롤업 상태별로 정렬되어 있습니다. 일반적으로 좋은 롤업에는 (있는 경우) iffy PR 한두 개, 여러 개의 maybe(표시되지 않은) PR, 그리고 다수의 always PR이 포함됩니다. 롤업에는 rollup=never PR을 절대 포함해서는 안 됩니다(bors가 이를 보장합니다).
롤업의 실제 절대 크기는 경험에 따라 달라질 수 있습니다. 롤업을 처음 만드는 사람은 iffy 1개, maybe 4개, always 5개로 시작할 수 있지만, 경험이 많은 사람은 iffy 1~2개, maybe 8개, always 10개로 롤업을 만들기도 합니다! 대규모 롤업이 필요한 경우는 드물지만, 직관이 쌓일수록 롤업에 PR을 포함할 때 위험을 더 잘 판단하게 됩니다.
PR의 롤업 상태를 낮추는 것을 주저하지 마십시오! rollup=always PR이 실패할 가능성이 있다는 직감이 든다면 rollup=maybe 또는 rollup=iffy로 표시하십시오. 표시되지 않은 maybe PR 중 상당수는 리뷰어가 롤업 적합성을 고려하지 않았기 때문에 그렇게 분류되었을 수 있으므로, 항상 비판적인 시각으로 골라내는 것이 좋습니다. 마찬가지로, 어떤 PR 때문에 롤업이 실패했다면 해당 PR의 롤업 상태를 변경하는 것을 고려해 볼 만합니다
일반적으로 CI 구성이나 부트스트래핑 과정을 건드리는 PR은 iffy일 가능성이 높으므로 신중하게 다뤄야 합니다. 반면 문서만 수정하는 PR은 보통 rollup=always입니다.
큰 diff나 서브모듈 변경이 있는 PR을 같은 롤업에 너무 많이 넣지 마십시오. 성능에 큰 영향을 줄 것으로 의심되는 PR도 넣지 말고, 그런 PR은 rollup=never로 표시하십시오.
롤업이 성공하기를 바라는 것이 당연하므로 iffy PR을 아예 넣지 않고 싶은 유혹이 들 수 있습니다. 하지만 PR 큐의 역할은 PR을 병합하는 것이 아니라 테스트하는 것임을 기억해 둘 필요가 있습니다. 따라서 iffy PR 때문에 롤업이 실패하는 것은 좋은 일입니다. 그 PR은 어차피 언젠가는 테스트해야 하고, 롤업에 포함되지 않았더라도 테스트하는 데 같은 시간이 들었을 것이기 때문입니다. iffy PR과 관련해 롤업을 바라보는 한 가지 관점은, 롤업이란 iffy PR에 어차피 필요한 CI 사이클에 다른 여러 PR이 편승하는 방법이라는 것입니다. 롤업에서 iffy PR을 완전히 피하면 결국 이런 PR이 큐에 오랫동안 방치되기 쉬우며, 이는 바람직하지 않습니다.
마찬가지로, never PR에도 기회가 돌아가도록 여분의 CI 사이클을 반드시 남겨 두십시오! 롤업을 만드는 사람이 본인뿐이라면 큐를 지켜보지 않는 시간에 그런 PR이 실행되도록 두는 것이 좋습니다. 하지만 요즘은 여러 시간대에 롤업 작성자가 있으므로, 큐의 상대적인 크기를 지켜보면서 never PR을 위해 CI 사이클 몇 개를 따로 남겨 두는 것이 대개 가장 좋습니다. 이런 PR이 쌓여 있을 때는 특히 그렇습니다.
롤업은 공정하게 만들도록 노력하십시오. 롤업은 큐에서 새치기하는 수단입니다. rollup=maybe PR의 경우, 새 PR이 오래된 PR보다 무조건 먼저 처리되지 않도록 가장 오래된 PR(해당 섹션의 맨 위)을 포함하도록 노력하십시오. 롤업에 넣은 PR보다 오래된 PR을 모두 포함할 필요는 없지만, 가장 오래된 PR은 포함하도록 노력하십시오. iffy에 대한 관점과 마찬가지로, 롤업을 큐에서 가장 오래된 PR의 CI 사이클에 다른 PR이 편승하는 방법으로 보면 유용합니다.
실패한 롤업
롤업이 실패했을 때 그 실패가 일시적인 것이었다면(예: 네트워크 문제나 타임아웃) @bors retry 명령을 실행하십시오. 일시적인 실패가 아니었다면 문제를 일으킨 PR을 찾은 다음, rust-logs-analyzer 댓글의 링크를 복사하여 Failed in <link_to_comment>, @bors r-라고 작성해 그 PR을 제외하십시오. 그러면 작성자나 리뷰어가 PR을 고칠 수 있도록 피드백을 주거나, 해당 PR이 원인이 아님을 확인해 줄 것입니다. 실패한 롤업 PR은 닫아도 됩니다.
문제를 일으킨 PR을 제외했다면, 그 PR을 빼고 롤업을 다시 만드십시오(1. 참조). 그러나 문제를 일으킨 PR을 찾기 어려울 때도 있습니다. 그런 경우에는 직관을 활용해 문제로 의심되는 PR을 빼고 롤업을 다시 만드십시오. 또 다른 방법은 의심되는 PR의 우선순위를 높이고 rollup=never(또는 iffy)로 표시한 다음, bors가 해당 PR을 단독으로 테스트하게 하여 가설을 확인하거나 기각하는 것입니다.
롤업이 계속 실패한다면 @bors rollup=never 명령을 실행하여 해당 PR이 앞으로 롤업에 포함되지 않도록 할 수 있습니다.