Thực thi các tiêu chuẩn mã trong git trước khi cam kết được chấp nhận

Question

Được rồi, đây là kịch bản: Một nhóm các nhà phát triển muốn đảm bảo tất cả mã mới khớp với các tiêu chuẩn mã hóa đã xác định và tất cả các bài kiểm tra đơn vị đều được gửi trước khi cam kết được chấp nhận. Đây là thủ thuật, tất cả các thử nghiệm cần chạy trên một máy kiểm tra chuyên dụng và chúng tôi không có quyền truy cập để sửa đổi máy chủ git vì vậy việc này phải được thực hiện bằng cách sử dụng một móc nối cục bộ trên mỗi máy dev.

Mặc dù thông số kỹ thuật khá nghiêm ngặt (ví dụ: chúng tôi không chuyển sang cửa sổ hoặc lật đổ), đây là vấn đề thực tế nên có sự linh hoạt nếu bạn có giải pháp gần như phù hợp.

• Chúng tôi đang sử dụng Git và * nix.
• Mã được cập nhật cần phải được gửi đến một máy chủ khác để chạy bộ thử nghiệm.
• Danh sách các tệp đã sửa đổi cần phải được cung cấp để đảm bảo chúng khớp với chuẩn mã hóa.
• Đó là một codebase khá lớn, vì vậy chúng tôi nên gửi lượng thông tin nhỏ nhất cần thiết để đảm bảo các bản sao giống hệt của codebase.
• Nếu các kiểm tra thất bại, một thông báo cần được hiển thị với lỗi và cam kết sẽ bị chặn.
• Giả sử chúng tôi tin tưởng nhóm dev của chúng tôi và không sao cho phép thử nghiệm được bỏ qua với tùy chọn --no-verify.

Câu hỏi: Cách tốt nhất để máy chủ thử nghiệm đồng bộ hóa với môi trường cục bộ để chạy thử nghiệm là gì? Một số loại hash-to-hash phù hợp với một bản vá git cho cam kết mới? Bỏ qua Git hoàn toàn và chỉ cần làm một rsync? Cái gì khác hoàn toàn?

Cập nhật 8/7/13: Tôi tự bắn vào chân bằng cách nhắc đến repo từ xa. Điểm không phải là để ngăn chặn các mã được đẩy đến repo chia sẻ/từ xa, nó để ngăn chặn các cam kết địa phương thậm chí xảy ra. Có hay không điều này sẽ được coi là một thực hành tốt nhất là không thực sự là điểm trong trường hợp này, vì điều này là cụ thể cho một nhóm nhỏ các nhà phát triển tất cả những người muốn chức năng chính xác này. Câu hỏi đặt ra là cách tốt nhất để đạt được mục tiêu.

Answer 1

Thêm một lệnh tùy chỉnh git đó:

1. Tạm thời không cam kết
2. Đẩy nó vào máy chủ từ xa
3. Chạy kiểm tra (sử dụng một máy chủ CI, post-receive móc, hoặc ssh)
4. Hoàn nguyên cam kết nếu các thử nghiệm không thành công

Tạo tệp thi hành được gọi là git-test-n-commit và đặt nó trong đường dẫn của bạn:

#!/bin/bash 
echo "Committing results..." 
git commit "$@" 
echo "Pushing to remote testing server..." 
git push remote-server-git-url remote-branch -f 
echo "Running tests" 
ssh remote-server 'cd my_repo; run-my-tests' || 
    (echo "Tests failed, undoing commit" && git reset HEAD^) 

Sau đó, thay vì gọi git commit ARGS, các nhà phát triển có thể gọi git test-n-commit ARGS. Nếu các bài kiểm tra vượt qua mã sẽ vẫn được cam kết. Nếu các bài kiểm tra thất bại, nó sẽ như thể nó không bao giờ được cam kết.

Answer 2

Móc cam kết cục bộ chắc chắn không phải những gì bạn muốn ở đây.

Yêu cầu của bạn là 'chúng tôi không có quyền truy cập để sửa đổi máy chủ git vì vậy việc này phải được thực hiện bằng cách sử dụng móc nối cục bộ trên mỗi máy dev' là hoàn toàn không có thật. Bạn luôn có thể thiết lập một kho lưu trữ khác là 'kiểm tra từ xa' mà bạn có toàn quyền kiểm soát (sau đó sẽ đồng bộ hóa với máy chủ git mà bạn không có quyền kiểm soát).

Khi bạn thiết lập điều khiển từ xa thử nghiệm này, bạn có thể thêm móc để chạy thử nghiệm của mình khi có bất kỳ sự cố nào. Nỗ lực để gõ git push test-remote my-branch để có được kết quả thử nghiệm là khá tối thiểu.

Continuous integration with Git

Ngoài ra kiểm tra Jenkins, gitlab, vv ...

---

Cập nhật sau 8/7/13:

Vì vậy, bạn thực sự muốn làm một số 'kiểm tra' trên một máy chủ từ xa để ngăn chặn các cam kết. Nếu bạn muốn ngăn chặn dựa trên nội dung của cam kết, hãy sử dụng móc pre-commit.See this question for how to get a list of changed files. Khi bạn có các tệp đã thay đổi đó, bạn có thể đưa chúng đến máy chủ từ xa bằng cách sử dụng scp hoặc rsync và chạy lệnh kiểm tra với ssh.

Nếu bạn cần kiểm tra thư cam kết sử dụng móc commit-msg.

Đây là một hướng dẫn tốt về móc: http://git-scm.com/book/en/Customizing-Git-Git-Hooks

Nó cũng đề cập đến một vài lý do tại sao nó có thể là một ý tưởng tồi.

Chúng thường được sử dụng để thực thi các chính sách nhất định, mặc dù điều quan trọng cần lưu ý là các tập lệnh này không được chuyển trong bản sao. Bạn có thể thực thi chính sách ở phía máy chủ để từ chối các cam kết đẩy không tuân thủ một số chính sách, nhưng hoàn toàn tùy thuộc vào nhà phát triển để sử dụng các tập lệnh này ở phía máy khách. Vì vậy, đây là những kịch bản để giúp các nhà phát triển, và họ phải được thiết lập và duy trì bởi họ, mặc dù họ có thể bị ghi đè hoặc sửa đổi bởi họ bất cứ lúc nào.

Answer 3

Câu trả lời ngắn:

KHÔNG

---

Long trả lời:

Không có khả năng để làm một cam kết vì một số móc địa phương kỳ lạ có vẻ kỳ lạ với tôi: bạn phải tách thực hiện cam kết (tức là lưu các thay đổi của bạn) từ việc xuất bản cam kết này.

Trong khi nó hợp lý một cách hợp lý để có móc pre-receive trên máy chủ git bạn đề cập đến thực thi quy tắc của bạn, nó sẽ là ấn tượng đối với repos của nhà phát triển của bạn: mỗi lần họ muốn lưu công việc của họ, thử một cái gì đó mới hoặc bất cứ điều gì , trước tiên họ phải đánh bóng mã của họ trước khi họ có thể thực hiện cam kết.

Điều này có thể phản tác dụng: mọi người sẽ cảm thấy như trở lại những ngày cũ tồi tệ khi họ phải cam kết bất kỳ điều gì để repo và mọi người có thể thấy lỗi của họ, kiểu mã sai và v.v. Bạn sẽ mất đi sự tự do mà DVCS mang lại cho bạn: phân nhánh giá rẻ, lịch sử địa phương trong khi duy trì một repo trung tâm cho mã sản xuất.

Không thi hành bất cứ điều gì khi thực hiện cam kết cục bộ.

Answer 4

Sau khi thiết lập máy chủ trung gian như những người khác đã đề xuất, hãy đặt pre-receive kết nối để chạy tập lệnh trên cam kết đến và chuẩn hóa nó theo tiêu chuẩn mã hóa của bạn. Các tiêu chuẩn mã hóa thường được xác định bởi các quy tắc thực thi máy tính. Không làm cho các nhà phát triển của bạn đi xung quanh tinh chỉnh khoảng trống ở đây và tither khi một kịch bản bash đơn giản hoặc bất cứ điều gì có thể làm điều đó cho họ. Và nếu bạn có một kịch bản để làm điều đó, tại sao làm cho các nhà phát triển chạy nó bằng tay khi nó có thể được chạy tự động trên mỗi push để repo trung gian của bạn.

Answer 5

Tôi nghĩ cách tiếp cận tốt nhất mà tôi đã thấy là git + gerrit + jenkins. Các gerrit giới thiệu một khái niệm về một changeset. Plugin jenkins gerrit có thể xây dựng mỗi changeset được xuất bản (chạy bất kỳ loại kiểm tra nào bạn muốn) và đánh dấu chúng là "đã xác minh", khi đó xác thực changeset có thể được hợp nhất thành một nhánh chính. Nếu changeset không thành công, người nhận sẽ nhận được email thông báo, sau đó anh ta có thể sửa đổi cam kết và cập nhật changeset.

Answer 6

Viết một Makefile rằng:

1. Bản sao các file hiện hành để kiểm tra máy chủ.

2. Tìm đầu ra của các bài kiểm tra đơn vị.

2.1. Nếu không có bất thường, hãy chạy 'git commit'

2.2 Nếu có bất thường, hãy báo lỗi.

Sử dụng Makefiles để thực hiện việc biên soạn VÀ các cam kết của tôi đã là một ơn trời. Tôi có thể tự động hóa việc định dạng và xóa tệp phức tạp trước khi cam kết.

Chỉnh sửa:

Tất nhiên, Makefiles không phải là điều duy nhất bạn có thể làm. Ant/Bash/các ngôn ngữ kịch bản khác có thể làm điều này cho bạn.