🥇Phân tích các yêu cầu hợp nhất trong GitLab bằng PVS-Studio for C#

Yêu GitLab và ghét lỗi? Bạn muốn cải thiện chất lượng mã nguồn của mình? Vậy thì bạn đã đến đúng nơi. Hôm nay chúng tôi sẽ cho bạn biết cách định cấu hình bộ phân tích PVS-Studio C# để kiểm tra các yêu cầu hợp nhất. Chúc mọi người có tâm trạng kỳ lân và đọc sách vui vẻ.

PVS Studio là công cụ xác định lỗi và lỗ hổng tiềm ẩn trong mã nguồn của các chương trình viết bằng C, C++, C# và Java. Hoạt động trên các hệ thống 64 bit trên Windows, Linux và macOS. Có thể phân tích mã được thiết kế cho nền tảng ARM 32 bit, 64 bit và nhúng.

Nhân tiện, chúng tôi đã phát hành PVS-Studio 7.08, trong đó chúng tôi đã làm rất nhiều thứ hấp dẫn. Ví dụ:

Trình phân tích C# cho Linux và macOS;
plugin cho Rider;
chế độ kiểm tra danh sách tập tin mới.

Chế độ kiểm tra danh sách tập tin

Trước đây, để kiểm tra một số tệp nhất định, cần phải chuyển tệp .xml có danh sách tệp tới máy phân tích. Nhưng vì điều này không thuận tiện lắm nên chúng tôi đã thêm khả năng chuyển .txt, điều này khiến cuộc sống trở nên rất đơn giản.

Để kiểm tra các tệp cụ thể, bạn phải chỉ định cờ --sourceFiles (-f) và truyền .txt cùng với danh sách các tệp. Nó trông như thế này:

pvs-studio-dotnet -t path/to/solution.sln -f fileList.txt -o project.json

Nếu bạn quan tâm đến việc thiết lập các yêu cầu kiểm tra cam kết hoặc kéo, bạn cũng có thể thực hiện việc đó bằng chế độ này. Sự khác biệt sẽ nằm ở việc lấy danh sách các tệp để phân tích và sẽ phụ thuộc vào hệ thống bạn đang sử dụng.

Nguyên tắc kiểm tra yêu cầu hợp nhất

Bản chất chính của việc kiểm tra là đảm bảo rằng các vấn đề được máy phân tích phát hiện trong quá trình hợp nhất không rơi vào chủ chi nhánh. Chúng tôi cũng không muốn phân tích toàn bộ dự án mỗi lần. Hơn nữa, khi sáp nhập các nhánh, chúng ta có danh sách các file đã thay đổi. Vì vậy, tôi khuyên bạn nên thêm kiểm tra yêu cầu hợp nhất.

Đây là giao diện của yêu cầu hợp nhất trước khi triển khai bộ phân tích tĩnh:

Nghĩa là, tất cả các lỗi trong nhánh thay đổi, sẽ chuyển đến nhánh chính. Vì chúng tôi không muốn điều này nên chúng tôi thêm phân tích và bây giờ sơ đồ trông như thế này:

Chúng tôi phân tích thay đổi2 và nếu không có lỗi, chúng tôi sẽ chấp nhận yêu cầu hợp nhất, nếu không chúng tôi sẽ từ chối yêu cầu đó.

Nhân tiện, nếu bạn quan tâm đến việc phân tích các cam kết và yêu cầu kéo cho C/C++, thì bạn có thể đọc về nó đây.

GitLab

GitLab là một công cụ vòng đời DevOps dựa trên web nguồn mở cung cấp hệ thống quản lý kho mã cho Git với wiki riêng, hệ thống theo dõi vấn đề, quy trình CI/CD và các tính năng khác.

Trước khi bắt đầu phân tích các yêu cầu hợp nhất, bạn cần đăng ký và tải dự án của mình lên. Nếu bạn không biết cách thực hiện việc này thì tôi khuyên bạn nên Bài viết đồng nghiệp của tôi.

Ghi. Phương pháp thiết lập môi trường được mô tả dưới đây là một trong những phương pháp khả thi. Mục đích là hiển thị các bước thiết lập môi trường cần thiết để phân tích và khởi chạy máy phân tích. Có lẽ trong trường hợp của bạn, sẽ tối ưu hơn nếu tách các giai đoạn chuẩn bị môi trường (thêm kho lưu trữ, cài đặt máy phân tích) và phân tích: ví dụ: chuẩn bị hình ảnh Docker với môi trường cần thiết và sử dụng chúng hoặc một số phương pháp khác.

Để hiểu rõ hơn điều gì sẽ xảy ra bây giờ, tôi khuyên bạn nên xem sơ đồ sau:

Máy phân tích yêu cầu .NET Core SDK 3 để hoạt động, vì vậy trước khi cài đặt máy phân tích, bạn cần thêm kho lưu trữ của Microsoft để cài đặt các phụ thuộc cần thiết cho máy phân tích. Thêm kho lưu trữ của Microsoft cho các bản phân phối Linux khác nhau được mô tả trong tài liệu tương ứng.

Để cài đặt PVS-Studio thông qua trình quản lý gói, bạn cũng cần thêm kho lưu trữ PVS-Studio. Việc thêm kho lưu trữ cho các bản phân phối khác nhau được mô tả chi tiết hơn trong phần tài liệu liên quan.

Máy phân tích yêu cầu khóa cấp phép để hoạt động. Bạn có thể nhận được giấy phép dùng thử tại trang tải xuống máy phân tích.

Ghi. Xin lưu ý rằng phương thức hoạt động được mô tả (phân tích các yêu cầu hợp nhất) cần có giấy phép Doanh nghiệp. Do đó, nếu bạn muốn thử chế độ hoạt động này, đừng quên cho biết trong trường “Thông báo” rằng bạn cần có giấy phép Doanh nghiệp.

Nếu yêu cầu hợp nhất xảy ra thì chúng tôi chỉ cần phân tích danh sách các tệp đã thay đổi, nếu không chúng tôi sẽ phân tích tất cả các tệp. Sau khi phân tích, chúng ta cần chuyển đổi nhật ký sang định dạng mà chúng ta cần.

Bây giờ, khi đã có thuật toán làm việc trước mắt, bạn có thể chuyển sang viết kịch bản. Để làm điều này, bạn cần thay đổi tập tin .gitlab-ci.yml hoặc nếu nó không tồn tại, hãy tạo nó. Để tạo nó, bạn cần nhấp vào tên dự án của bạn -> Thiết lập CI/CD.

Bây giờ chúng ta đã sẵn sàng để viết kịch bản. Trước tiên hãy viết mã sẽ cài đặt máy phân tích và nhập giấy phép:

before_script:
  - apt-get update && apt-get -y install wget gnupg 

  - apt-get -y install git
  - wget https://packages.microsoft.com/config/debian/10/
packages-microsoft-prod.deb -O packages-microsoft-prod.deb
  - dpkg -i packages-microsoft-prod.deb
  - apt-get update
  - apt-get install apt-transport-https
  - apt-get update
  
  - wget -q -O - https://files.viva64.com/etc/pubkey.txt | apt-key add -
  - wget -O /etc/apt/sources.list.d/viva64.list
https://files.viva64.com/etc/viva64.list
  - apt-get update
  - apt-get -y install pvs-studio-dotnet

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY
  - dotnet restore "$CI_PROJECT_DIR"/Test/Test.sln

Vì quá trình cài đặt và kích hoạt phải diễn ra trước tất cả các tập lệnh khác nên chúng tôi sử dụng nhãn đặc biệt before_script. Hãy để tôi giải thích đoạn này một chút.

Chuẩn bị lắp đặt máy phân tích:

  - wget https://packages.microsoft.com/config/debian/10/
packages-microsoft-prod.deb -O packages-microsoft-prod.deb
  - dpkg -i packages-microsoft-prod.deb
  - apt-get update
  - apt-get install apt-transport-https
  - apt-get update

Thêm kho lưu trữ và phân tích PVS-Studio:

  - wget -q -O - https://files.viva64.com/etc/pubkey.txt | apt-key add -
  - wget -O /etc/apt/sources.list.d/viva64.list
https://files.viva64.com/etc/viva64.list
  - apt-get update
  - apt-get -y install pvs-studio-dotnet

Kích hoạt giấy phép:

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NAME - Tên tài khoản.

$PVS_KEY - chìa khóa sản phẩm.

Khôi phục sự phụ thuộc của dự án ở đâu $CI_PROJECT_DIR – đường dẫn đầy đủ đến thư mục dự án:

  - dotnet restore "$CI_PROJECT_DIR"/Path/To/Solution.sln

Để phân tích chính xác, dự án phải được xây dựng thành công và các phần phụ thuộc của nó phải được khôi phục (ví dụ: phải tải xuống các gói NuGet cần thiết).

Bạn có thể đặt các biến môi trường chứa thông tin giấy phép bằng cách nhấp vào Cài đặt, và sau - trên CI/CD.

Trong cửa sổ mở ra, tìm mục Biến, bấm vào nút bên phải Mở rộng và thêm các biến. Kết quả sẽ trông như thế này:

Bây giờ bạn có thể chuyển sang phân tích. Đầu tiên, hãy thêm một tập lệnh để phân tích đầy đủ. Đến lá cờ -t chúng tôi chuyển đường dẫn đến giải pháp cho cờ -o ghi đường dẫn đến tập tin sẽ ghi kết quả phân tích. Chúng tôi cũng quan tâm đến mã trả lại. Trong trường hợp này, chúng tôi quan tâm đến việc dừng hoạt động khi mã trả về chứa thông tin cảnh báo đã được đưa ra trong quá trình phân tích. Đoạn này trông như thế này:

job:
  script:
  - exit_code=0
  - pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -o 
PVS-Studio.json || exit_code=$?
  - exit_code=$((($exit_code & 8)/8))
  - if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fi

Mã trả về hoạt động theo nguyên tắc mặt nạ bit. Ví dụ: nếu cảnh báo được đưa ra do kết quả phân tích thì mã trả về sẽ bằng 8. Nếu giấy phép hết hạn trong vòng một tháng thì mã trả về sẽ bằng 4. Nếu phát hiện lỗi trong quá trình phân tích, và giấy phép hết hạn trong vòng một tháng, mã trả về, cả hai giá trị sẽ được ghi: cộng các số lại với nhau và nhận mã trả về cuối cùng - 8+4=12. Do đó, bằng cách kiểm tra các bit tương ứng, có thể thu được thông tin về các trạng thái khác nhau trong quá trình phân tích. Mã trả lại được mô tả chi tiết hơn trong phần "Mã trả lại pvs-studio-dotnet (Linux / macOS)" của tài liệu "Kiểm tra các dự án Visual Studio/MSBuild/.NET Core từ dòng lệnh bằng PVS-Studio".

Trong trường hợp này, chúng tôi quan tâm đến tất cả các mã trả lại có số 8 xuất hiện.

  - exit_code=$((($exit_code & 8)/8))

Chúng ta sẽ nhận được 1 khi mã trả về chứa bit của số mà chúng ta quan tâm, nếu không chúng ta sẽ nhận được 0.

Đã đến lúc thêm phân tích yêu cầu hợp nhất. Trước khi chúng ta làm điều này, hãy chuẩn bị một nơi cho kịch bản. Chúng tôi chỉ cần thực thi nó khi có yêu cầu hợp nhất. Nó trông như thế này:

merge:
  script:
  only:
  - merge_requests

Hãy chuyển sang kịch bản. Tôi đã phải đối mặt với thực tế là máy ảo không biết gì về nguồn gốc / chủ. Vậy hãy giúp cô ấy một chút nhé:

  - git fetch origin

Bây giờ chúng ta nhận được sự khác biệt giữa các nhánh và lưu kết quả vào txt tài liệu:

  - git diff --name-only origin/master $CI_COMMIT_SHA > pvs-fl.txt

Где $CI_COMMIT_SHA – hàm băm của lần xác nhận cuối cùng.

Tiếp theo, chúng ta bắt đầu phân tích danh sách file bằng cờ -f. Chúng tôi chuyển tệp .txt đã nhận trước đó vào đó. Chà, bằng cách tương tự với phân tích đầy đủ, chúng tôi xem xét mã trả về:

  - exit_code=0
  - pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -f 
pvs-fl.txt -o PVS-Studio.json || exit_code=$?
  - exit_code=$((($exit_code & 8)/8))
  - if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fi

Tập lệnh hoàn chỉnh để kiểm tra yêu cầu hợp nhất sẽ trông như thế này:

merge:
  script:
  - git fetch origin
  - git diff --name-only origin/master $CI_COMMIT_SHA > pvs-fl.txt
  - exit_code=0
  - pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -f 
pvs-fl.txt -o PVS-Studio.json || exit_code=$?
  - exit_code=$((($exit_code & 8)/8))
  - if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fi
  only:
  - merge_requests

Tất cả những gì còn lại là thêm chuyển đổi nhật ký sau khi tất cả các tập lệnh đã được xử lý. Chúng tôi sử dụng nhãn after_script và tiện ích chuyển đổi plog:

after_script:
  - plog-converter -t html -o eLog ./PVS-Studio.json

Tính thiết thực chuyển đổi plog là một dự án nguồn mở được sử dụng để chuyển đổi các báo cáo lỗi trình phân tích cú pháp thành nhiều dạng khác nhau, chẳng hạn như HTML. Mô tả chi tiết hơn về tiện ích này được đưa ra trong tiểu mục "Tiện ích chuyển đổi Plog" phần tài liệu liên quan.

Nhân tiện, nếu bạn muốn làm việc thuận tiện với các báo cáo .json cục bộ từ IDE, thì tôi đề xuất cắm vào cho IDE Rider. Việc sử dụng nó được mô tả chi tiết hơn trong Tài liệu liên quan.

Để thuận tiện, đây là .gitlab-ci.yml đầy đủ:

image: debian

before_script:
  - apt-get update && apt-get -y install wget gnupg 

  - apt-get -y install git
  - wget https://packages.microsoft.com/config/debian/10/
packages-microsoft-prod.deb -O packages-microsoft-prod.deb
  - dpkg -i packages-microsoft-prod.deb
  - apt-get update
  - apt-get install apt-transport-https
  - apt-get update
  
  - wget -q -O - https://files.viva64.com/etc/pubkey.txt | apt-key add -
  - wget -O /etc/apt/sources.list.d/viva64.list
https://files.viva64.com/etc/viva64.list
  - apt-get update
  - apt-get -y install pvs-studio-dotnet

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY
  - dotnet restore "$CI_PROJECT_DIR"/Test/Test.sln

merge:
  script:
  - git fetch origin
  - git diff --name-only origin/master $CI_COMMIT_SHA > pvs-fl.txt
  - exit_code=0
  - pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -f 
pvs-fl.txt -o PVS-Studio.json || exit_code=$?
  - exit_code=$((($exit_code & 8)/8))
  - if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fi
  only:
  - merge_requests

job:
  script:
  - exit_code=0
  - pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -o 
PVS-Studio.json || exit_code=$?
  - exit_code=$((($exit_code & 8)/8))
  - if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fi
  
after_script:
  - plog-converter -t html -o eLog ./PVS-Studio.json

Khi bạn đã thêm mọi thứ vào tệp, hãy nhấp vào Cam kết thay đổi. Để thấy rằng mọi thứ đều chính xác, hãy truy cập CI / CD -> Đường ống -> Chạy. Một cửa sổ máy ảo sẽ mở ra, ở cuối cửa sổ này sẽ có thông tin sau:

cái cưa Công việc đã thành công - thành công, mọi chuyện đều ổn. Bây giờ bạn có thể kiểm tra những gì bạn đã làm.

Ví dụ công việc

Để có một ví dụ về công việc, hãy tạo một dự án đơn giản (trong chủ) sẽ chứa một số tệp. Sau đó, ở nhánh khác, chúng tôi sẽ chỉ thay đổi một tệp và cố gắng thực hiện yêu cầu hợp nhất.

Hãy xem xét hai trường hợp: khi tệp đã sửa đổi có lỗi và khi không. Đầu tiên, một ví dụ có lỗi.

Giả sử có một tệp trong nhánh chính Chương trình.cs, không có lỗi nhưng ở nhánh khác, nhà phát triển đã thêm mã sai và muốn thực hiện yêu cầu hợp nhất. Anh ta mắc phải sai lầm gì không quá quan trọng, cái chính là nó tồn tại. Ví dụ, người điều hành đã quên quăng (Đúng, như vậy là sai):

void MyAwesomeMethod(String name)
{
  if (name == null)
    new ArgumentNullException(....);
  // do something
  ....
}

Hãy xem kết quả phân tích một ví dụ có lỗi. Ngoài ra, để đảm bảo rằng chỉ có một tệp được phân tích cú pháp, tôi đã thêm cờ -r đến dòng khởi chạy pvs-studio-dotnet:

Chúng tôi thấy rằng trình phân tích đã tìm thấy lỗi và không cho phép hợp nhất các nhánh.

Hãy kiểm tra ví dụ không có lỗi. Sửa mã:

void MyAwesomeMethod(String name)
{
  if (name == null)
    throw new ArgumentNullException(....);
  // do something
  ....
}

Hợp nhất kết quả phân tích yêu cầu:

Như chúng ta có thể thấy, không tìm thấy lỗi nào và quá trình thực thi tác vụ đã thành công, đó là điều chúng tôi muốn kiểm tra.

Kết luận

Việc loại bỏ mã xấu trước khi sáp nhập các nhánh rất thuận tiện và dễ chịu. Vì vậy, nếu bạn đang sử dụng CI/CD, hãy thử nhúng máy phân tích tĩnh để kiểm tra. Hơn nữa, việc này được thực hiện khá đơn giản.

Cảm ơn bạn đã quan tâm của bạn.

Nếu bạn muốn chia sẻ bài viết này với khán giả nói tiếng Anh, vui lòng sử dụng liên kết dịch: Nikolay Mironov. Phân tích các yêu cầu hợp nhất trong GitLab bằng PVS-Studio cho C#.

Nguồn: www.habr.com

Phân tích các yêu cầu hợp nhất trong GitLab bằng PVS-Studio cho C#

Chế độ kiểm tra danh sách tập tin

Nguyên tắc kiểm tra yêu cầu hợp nhất

GitLab

Ví dụ công việc

Kết luận

Thêm một lời nhận xét Hủy bỏ trả lời