Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Add branch kernel-ci from https://github.com/lustre/linux.git

Đang mở
  • Có gì không ổn?
#3,243 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
48/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
git, github, linux
Lĩnh vực
ci-cd

Hướng nghiên cứu

The issue requests monitoring the kernel-ci branch of https://github.com/lustre/linux.git, with main defconfigs that enable Lustre and weekly updates. Start by reading the repository's branch and build configuration entry points to find how monitored branches and defconfig filters are declared. Done means KernelCI builds that branch with the requested coverage and sends reports to the listed recipients; the issue does not identify the files or configuration format.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Context

Lustre is an open-source (GPLv2), distributed parallel file system designed for scalability, high-performance, and high-availability. Lustre is being upstreamed to the Linux kernel (https://lwn.net/Articles/1025268/). We're aiming to improve test coverage of Lustre on all supported Linux platforms, including those not typically used in HPC.

Form

Each git kernel branch is monitored every hour by kernelci.org. Whenever a new
revision is detected, it will be built for a number of combinations of
architectures, defconfigs and compilers. Then a build report will be sent,
some tests will be run and test reports will also be sent.

Please provide the information described below in order to add a new branch to
kernelci.org:

  • Which Git branch do you want to add?

⇨ Git repo URL: https://github.com/lustre/linux.git

⇨ Git branch name: kernel-ci

  • How much build coverage do you need for your branch?

Generally speaking, a good rule is to build fewer variants for branches that
are "further" away from mainline and closer to individual developers. This can
be fine-tuned with arbitrary filters, but essentially there are 3 main options:

  1. Build everything, including allmodconfig, which amounts to about 220 builds.
    This is we do with linux-next.

  2. Skip a few things such as allmodconfig as it's very long to build and
    doesn't really boot, and also architectures that are less useful such as MIPS
    which saves 80 builds and doesn't have many test platforms in KernelCI. This
    is we do with some subsystems such as linux-media.

  3. Build only the main defconfig for each architecture to save a lot of build
    power, get the fastest results and highest boots/builds ratio. This is what do
    with some maintainer branches such as linusw' GPIO branch.

⇨ Build coverage choice: Ideally, start with 3 - build only the main defconfig for each architecture. The configuration must have Lustre enabled.

  • How often do you expect this branch to be updated?

If you push once a week or less, it's easier to allow for many build variants
as this reduces the build load on average. Conversely, if you push several
times every day then a small set of builds should be used.

It's also possible to increase the build capacity if needed but this comes with
a cost. Avoiding unnecessary builds is always a good way to reduce turnaround
time and not waste resources.

⇨ Estimated frequency: Weekly

  • Who should the email reports be sent to?

Standard email reports inlude builds and basic tests that are run on all
platforms. Please provide a list of email recipients for these. Typical ones
are the regular KernelCI reports list, kernel mailing lists associated with the
changes going into the branch and related maintainers.

⇨ Recipients: [email protected], [email protected], [email protected], [email protected], [email protected]

Ngôn ngữ chính
Python
Star
119
Fork
109
Merge trung bình
8 giờ 1 phút
Pull request đã merge (30 ngày)
13

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của kernelci/kernelci-core

Tất cả issue của kernelci/kernelci-core

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.