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. 라이브러리 팀이 제안을 리뷰한 뒤 차단할 만한 우려 사항이 없으면 구현 PR을 rust-lang/rust에 제출하십시오.
   • PR에는 트리 내 rustc-dev-guide에 추가할 해당 생태계/통합 테스트 작업/구성 요소 지원 페이지를 함께 포함해야 하며, 실패 대응 절차가 잘 문서화되어 있는지 확인해야 합니다(아래 참조). MCP와 이슈를 링크하십시오.
5. 인프라 팀이 구현 PR을 리뷰합니다. 승인되면 해당 생태계/통합 테스트 작업/구성 요소가 rust-lang/rust PR CI 또는 Full Merge CI에서 실행됩니다.

생태계 및 통합 테스트 작업/구성 요소 정책

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

참고: 이 정책은 생태계 테스트 작업/구성 요소를 추가하는 일을 번거롭고 성가시게 만들려는 것이 아닙니다. 저희는 필요한 배경 정보를 미리 수집하고(특히 실현 가능한 실패 대응 절차를 함께 마련하고) 싶을 뿐입니다. 이는 테스트 작업/구성 요소가 실제로 실패하여 전혀 관련 없는 PR의 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