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

How should <branch/change checkers> assemble the list of files to check ? #UMDP3_check

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

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

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
20/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
git, python
Lĩnh vực
tooling

Hướng nghiên cứu

Bắt đầu bằng cách so sánh các đường dẫn branch, trunk, working-copy, command-line và suite riêng biệt của checker UMDP3 với hành vi fcm bdiff hiện có, bao gồm cả phiên bản git. Xác định những tệp hoặc dòng mà một checker thay đổi nên nhắm đến trong từng ngữ cảnh runtime, đồng thời ghi lại thiết kế và các tiêu chí chấp nhận thu được.

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

Mô tả

This question arises from looking at UMDP3 checker, but it could be applied to any scripts we want to target code being changed.

The original UMDP3 checker was grown not designed. This means it has several, completely separate ways of deciding what files to check based on branch v trunk v WC and command line v suite
Originally, IIRC, as a script run manually on a WC it used output from 'fcm bdiff' to get a list of files to check.

This doesn't work in quite the same way in most other circumstances though.

  • in rose-stem it can only see changes committed to the (mirror) branch
  • when dealing with the trunk, bdiff produces no results
  • When rose-stem is run on a 'test branch' it tries to auto correct to the dev branch.

Ultimately this means that the current structure of the (AI translated code) branches quite early on based on "is trunk" and "is suite" rather than calling a "get checklist" function which could handle a vairety of methods beghind the scene.

The result is a range of code specific to the runtime circumstances (umdp3 checker really is about 3 separate codes with little overlap in anything other than intent...)

Secondary issues are that when working on a WC (and possibly a branch, but not in rose-stem ==I think==) it also relies on the full output of fcm bdiff to only check the changed lines. Or when run in rose stem, it tries to decide if "other repos" (linked tickets) are in play and then tries to check the code in them too - but doesn't have a branch - only the fully extracted code to look at.

At present, the git version of 'fcm bdiff', while superior in many ways to the actual 'fcm bdiff', does not have the option to generate a list of changed/added/deleted lines - It could be added, however I'm not sure we should be restricting the checks to that level....

And /finally/ the output of UMDP3 checker in the automatic tests on the trunk (nigtly/weekly) produce so much spurious output, it seems noone is looking at them any more.

So the question is : what is it we want any change checker to check ?

  1. All the code ?
  2. or only the changed files ?
  3. or only the changed lines ?

approach 1 has the following issues :

  • time/performance - there might be a lot of code to check.
  • spotting 'issues' that pre-existed the change in question (devs don't like this)
    approach 2 can still spot 'issues' that aren't a result of the change, but less of them as it's only dealing with a smaller subset of files.

approach 3 is only available when looking at a branch, and has the small hickup that in my tests, it fails to highlight the removal of an "implicit None" as that's not an issue on 'a line' but requires a check which looks at the whole file - which it's currently not getting..

So - as we prgogress from FCM to Git - and I'm looking at it anyway, if we were designing something to target checks within a change - what would we want it to do ?

Ngôn ngữ chính
Python
Star
9
Fork
19
Merge trung bình
5 ngày 48 phút
Pull request đã merge (30 ngày)
4

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

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 MetOffice/SimSys_Scripts

Tất cả issue của MetOffice/SimSys_Scripts

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.