rust-lang/rust CI에 생태계/통합 테스트 작업/구성 요소 추가하기

범위

이 정책은 추가 아티팩트를 빌드하고 테스트하는 작업이 rust-lang/rust PR CI 또는 Full CI(“CI”)를 실패하게 하거나 실패 메시지를 발생시켜, rust-lang/rust CI를 함께 사용하는 다른 rust-lang/rust 기여자에게 영향을 줄 수 있는 새로운 생태계 및 통합 테스트 작업/구성 요소 추가 제안에 적용됩니다.

예를 들면 (전부는 아님):

• 생태계 테스트 작업: Rust for Linux 또는 Fuchsia.
• 통합 테스트 컴포넌트: GCC 코드젠 백엔드 또는 Cranelift 코드젠 백엔드.

배경

rust-lang/rust는 PR CI에서 소규모의 빌드/테스트 작업 집합을 실행하며(더 빠르고 비용이 적게 들며 덜 철저함), Full CI에서는 훨씬 더 큰 규모의 빌드/테스트 작업 집합을 실행합니다. PR CI는 보통 약 1시간이 걸리고, Full CI는 보통 약 3시간이 걸립니다. 다음과 같은 에코시스템 및 통합 테스트 작업/컴포넌트를 두는 것은:

• 우발적으로 실패할 수 있거나; 또는
• 실제로 실패하지만 실패에 대해 누구에게 문의해야 하는지 또는 누가 실패를 수정할 책임이 있는지 명확하지 않거나; 또는
• 그 외에 잘 문서화된 테스트 작업 메인테이너와 실패 프로토콜이 없는 경우

이제 실패를 처리하거나 애초에 테스트 작업이 왜 실패했는지 이해해야 하는 다른 기여자들에게 많은 마찰과 좌절감을 줄 수 있으며, 이는 이제 그들의 PR을 막고 있을 수도 있습니다. rust-lang/rust CI를 사용하는 모든 사람은 이를 책임감 있게 사용할 것으로 기대됩니다.

이를 돕기 위해, rust-lang/rust CI에 생태계/통합 테스트 작업/구성 요소를 추가하는 것을 제안하고자 한다면 아래에 설명된 절차를 따르십시오.

rust-lang/rust CI에 생태계/통합 테스트 작업/구성 요소를 추가하는 절차

1. Zulip(#t-infra)에서 인프라 팀에 제안된 테스트 작업/구성 요소를 위한 용량이 있는지 문의하십시오.
2. 주요 변경 제안(MCP)을 사용하여 제안하십시오.
   • 작성 완료된 에코시스템 및 통합 테스트 작업/컴포넌트 정책을 포함하십시오(아래 참조).
3. MCP가 재청되어 승인되면, rust-lang/rust에 해당 제안에 관한 새 이슈를 생성하여 MCP에 링크하고, @rustbot label +I-libs-nominated를 통해 라이브러리 팀 리뷰를 위한 제안을 지명하십시오.
   • MCP에 링크하십시오.
4. 라이브러리 팀이 제안을 검토하고 막는 우려 사항이 없으면, rust-lang/rust에 구현 풀 리퀘스트를 제출하십시오.
   • 해당 풀 리퀘스트에는 트리 내 rustc-dev-guide에 부속 생태계/통합 테스트 작업/구성 요소 지원 페이지를 포함해야 하며, 실패 프로토콜이 잘 문서화되어 있는지 확인해야 합니다(아래 참조). MCP와 이슈에 링크하십시오.
5. 인프라 팀이 구현 풀 리퀘스트를 검토합니다. 승인되면, 해당 생태계/통합 테스트 작업/구성 요소는 rust-lang/rust PR CI 또는 Full Merge CI에서 실행됩니다.

에코시스템 및 통합 테스트 작업/컴포넌트 정책

MCP의 일환으로 이 템플릿(구분선 아래)을 복사하여 작성해 주십시오. 정책 질문/설명 자체는 인용 블록으로 표시됩니다. MCP 작성자가 제공해야 하는 정보는 내용이 대체되어야 하는 기울임체 문장으로 표시되어 있습니다.

참고: 이 정책의 의도는 생태계 테스트 작업/구성 요소를 추가하는 것을 성가시고 번거롭게 만들려는 것이 아닙니다. 저희는 단지 테스트 작업/구성 요소가 실패할 경우, 그리고 실패할 때 완전히 무관한 풀 리퀘스트의 PR/Full Merge CI를 막을 수 있는 상황에서 다른 rust-lang/rust 기여자들이 겪을 수 있는 잠재적 불만을 최소화하기 위해, 필요한 배경 정보를 사전에(특히 실행 가능한 실패 프로토콜을 함께 고민하여) 수집하고자 할 뿐입니다.

## Ecosystem and Integration Test Job/Component Policy

The ecosystem/integration test job/component ("test job/component") proposed for the
[rust-lang/rust] CI must:

- Be approved by the compiler team through a proposed MCP, where the MCP is seconded by a compiler
  team member, and the MCP is accepted with no blocking concerns.
- Have no blocking concerns from the library team.
- Have the implementation PR be reviewed and approved by the infrastructure team.
- Be properly documented on [rustc-dev-guide] (preferably as part of the implementation PR).

Please complete the sections below so [rust-lang/rust] teams can have sufficient context about the 
proposed test job/component.

### Test job/component rationale

> What does this test job/component do?
>
> - If an ecosystem test job/component is being proposed, can you briefly describe the intended
>     ecosystem users?

*Please provide responses here, replacing this sentence.*

> What [rust-lang/rust] changes can potentially break the test job/component?
>
> E.g. changes to rustc, standard library, bootstrap or tools (like clippy/rustfmt/cargo).

*Please provide responses here, replacing this sentence.*

> Why does this test job/component need to be part of the [rust-lang/rust] PR and/or Full Merge CI?

*Please provide responses here, replacing this sentence.*

> If the test job/component will block on failure, why does it need to block?

*Please provide responses here, replacing this sentence.*

> If the test job/component will not block on failure initially but is intended to eventually become
> blocking:
>
> - Why will it become blocking?
> - When will it become blocking?

*Please provide responses here, replacing this sentence.*

### Test job/component maintainers

> The proposed test job/component for [rust-lang/rust] CI must have at least one dedicated test
> job/component maintainer. The test job/component maintainers understand that they will be pinged
> or otherwise contacted about the ecosystem/integration test job/component, particularly for (but 
> not limited to) its failures.
>
> **Please list who will be maintaining this ecosystem/integration test job/component here. Please
> format the github handles in the style:**
>
> ```
> [@github_handle_1](https://github.com/github_handle_1)
> [@github_handle_2](https://github.com/github_handle_2)
> ```
>
> NOTE: For future readers, you can paste the usernames without formatting them as links via
> **ctrl-shift-v**.

*Please list test job/component maintainers here with the formatting advice above, replacing this
sentence.*

> **NOTE: If an ecosystem/integration test job/component no longer has an active dedicated
> maintainer (or maintainers), and if [rust-lang/rust] teams find the ecosystem/integration test
> job/component causes significant burden or becomes irrelevant, then the ecosystem/integration test
> job/component may be removed.**

### CI infrastructure considerations

> You should ask the Infrastructure Team on the
> [`#t-infra`](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra) zulip channel when
> proposing a new ecosystem/integration test job/component to check if there's capacity for the test
> job/component.
>
> - Does the ecosystem/integration test job/component require substantial CI resources (storage and/
>   or CI time)? In particular, will it require large runners?

*Please provide responses here, replacing this sentence. If there is a zulip topic discussing it
with the Infrastructure Team, please include the zulip topic link here.*

### Features and implementation details

> Does the proposed test job/component intend to use any unstable features?
>
> - If so, are the unstable features ready for exposure (e.g. must an unstable feature be completely
>   reworked)?
> - For ecosystem test jobs/components, are the unstable features ready for such exposure to the
>   ecosystem, and are the feature stakeholders ready for such usage?

*Please provide responses here, replacing this sentence.*

> Does the proposed test job/component intend to intentionally depend on any implementation details?
> This may include but is not limited to: unstable/internal compiler/tool flags and behaviors,
> `RUSTC_BOOTSTRAP` usages, standard library implementation details, etc.
>
> - If so, are there plans to shrink or expand such dependencies in the future?

*Please provide responses here, replacing this sentence.*

### Failure protocol: what to do if the job/component breaks/fails?

> **NOTE: If the artifacts of an ecosystem/integration test job/component are not shipped as part of
> a distribution component/toolchain, the test job/component may be temporarily disabled to unblock
> [rust-lang/rust] PR CI or Full Merge CI without receiving prior approval from the test
> job/component maintainers. The test job/component maintainers will be pinged or otherwise notified
> about the test job/component being disabled.**

> How can the test job/component maintainers be contacted in case of failure? By default, it is
> assumed that the test job/component maintainer can be pinged via their GitHub handles.

*Please provide responses here, replacing this sentence.*

> (If applicable) If the addition of an ecosystem/integration test job is being proposed:
>
> - How can the test job be run in CI? If so, is there a try job (`try-job: ...`) invocation? What's
>   the job name?
> - Can the test job be run locally? If so, how?

*If applicable, please provide responses here, replacing this sentence. Otherwise, you can ignore
this question.*

> (If applicable) If the addition of an ecosystem/integration test component is being proposed:
>
> - Which existing CI jobs will be building and testing this test component?
> - Can they be built and ran as part of a try job? If so, what are the job names and the try job
>   (`try-job: ...`) invocations?
> - Can the test component be built and run locally? If so, how?

*If applicable, please provide responses here, replacing this sentence. Otherwise, you can ignore
this question.*

> How can the test job/component be disabled in the event of spurious failures that are blocking PR
> and/or Full Merge CI?

*Please provide responses here, replacing this sentence.*

> If a PR breaks the test job/component:
>
> - If the breakage seems **spurious** and retrying does not resolve the spurious breakage, the test
>   job may be **temporarily disabled** (see below).
> - If the breakage is **intentional**, how will this be resolved?
> - If the breakage is **unintentional**, is the PR author expected to fix the breakage?

*Please provide responses here, replacing this sentence.*

### Dependencies, build/test environments and reliability

> Does the test job/component involve any custom build systems that are not used in the regular
> [rust-lang/rust] CI jobs?

*Please provide responses here, replacing this sentence.*

> Does the test job/component depend on external resources (e.g. external servers) that may be
> subject to network connectivity?
>
> - If so, does the infrastructure team need to help maintain a mirror of the required assets?

*Please provide responses here, replacing this sentence.*

> Are there any potential sources of spurious failures due to the test job/component?

*Please provide responses here, replacing this sentence.*

> Are there any other unusual requirements (build environment, dependencies, etc.)?

*Please provide responses here, replacing this sentence.*


[rust-lang/rust]: https://github.com/rust-lang/rust
[rustc-dev-guide]: https://github.com/rust-lang/rustc-dev-guide