Kiểm tra tích hợp trong các dự án OSS - làm thế nào để xử lý xác thực của bên thứ 3?


10

Một trong những dự án sở thích (mã nguồn mở) của tôi là một công cụ sao lưu mà làm cho các bản sao lưu ẩn của kho từ GitHub, Bitbucket, vv
Nó kêu gọi API hosters để có được một danh sách các kho, và sau đó nó sử dụng Git / Mercurial / bất cứ điều gì để clone / kéo các kho lưu trữ đến máy tính cục bộ.

Vì vậy, tôi có các bài kiểm tra tích hợp trong đó tôi đang gọi API GitHub, với xác thực.
(và khi tính năng nhân bản / kéo kết thúc, có thể sẽ có các thử nghiệm lưu trữ bản sao từ GitHub và cũng cần xác thực)

Tôi đã tạo một người dùngmột tổ chức đặc biệt để sử dụng trong các thử nghiệm tích hợp này.

Vấn đề: Tôi không thể mã hóa mật khẩu ở đâu đó trong mã nguồn vì đó là nguồn mở và mã được công khai trên GitHub.


Tôi làm cái gì bây giờ

Trong các thử nghiệm, tôi nhận được tất cả tên người dùng, mật khẩu và tên kho lưu trữ từ các biến môi trường.
Đây là một ví dụ :

config.Name = TestHelper.EnvVar("GithubApiTests_Name");
config.Password = TestHelper.EnvVar("GithubApiTests_PW");

( TestHelper.EnvVarlà một phương thức trợ giúp lấy giá trị của biến môi trường và đưa ra một ngoại lệ khi nó không tồn tại)

Sau đó, tôi có một tệp bó đặt các biến môi trường đó.
Cái thực ( environment-variables.bat) được gọi trong tập lệnh xây dựng của tôi và trước khi thực hiện các thử nghiệm, nhưng bị bỏ qua trong kiểm soát nguồn, vì vậy nó không thực sự nằm trong kho lưu trữ của tôi.

Có gì trong kiểm soát nguồn là environment-variables.bat.sample, thiết lập biến môi trường tương tự, nhưng với mật khẩu giả:

rem copy/rename this file to environment-variables.bat

echo Setting environment variables for integration tests...

set GithubApiTests_Name=scm-backup-testuser
set GithubApiTests_OrgName=scm-backup-testorg
set GithubApiTests_PW=not-the-real-password
set GithubApiTests_Repo=scm-backup

Vì vậy, tôi có thể sao chép kho lưu trữ vào máy của mình, đổi tên tệp này thành environment-variables.bat, thay thế mật khẩu giả bằng mật khẩu thật và tất cả các kiểm tra tích hợp sẽ hoạt động.

Điều này cũng hoạt động với Tích hợp liên tục - Tôi đang sử dụng AppVeyor và ở đó tôi có thể đặt các biến môi trường này trong giao diện người dùng web .


Những gì tôi không thích về nó

Tôi nghĩ rằng đó không phải là một giải pháp tốt cho một dự án OSS, và đặc biệt không phải cho dự án này :

Về lý thuyết, một người đóng góp cho dự án của tôi sẽ có thể chạy các bài kiểm tra tích hợp ngay bây giờ bằng cách:

  • tạo người dùng thử nghiệm và tổ chức thử nghiệm của riêng mình trên GitHub
  • tạo một số kho kiểm tra
  • tạo phiên bản của riêng mình environment-variables.batvới các giá trị khác nhau

Vấn đề là ứng dụng của tôi sẽ có thể sao lưu nhiều máy chủ lưu trữ mã nguồn.
Ngay bây giờ, nó chỉ hỗ trợ GitHub, nhưng sẽ dễ dàng thêm hỗ trợ cho nhiều máy chủ lưu trữ hơn bằng cách thêm một vài lớp thực hiện các giao diện phù hợp.

Vì vậy, khi tôi triển khai hỗ trợ cho nhiều máy chủ lưu trữ sau này, số lượng biến môi trường sẽ tăng lên.
Để có thể thực hiện tất cả các thử nghiệm tích hợp, một người đóng góp tiềm năng sẽ tạo ra kho lưu trữ người dùng, tổ chức và thử nghiệm của riêng anh ta tại GitHub, Bitbucket, GitLab, .... và biết bao nhiêu người nữa và thêm tất cả chúng vào environment-variables.batphiên bản của anh ta .

Có một giải pháp tốt hơn làm thế nào để làm điều này trên một dự án nơi mã được công khai?

Tôi biết rằng các dự án khác làm một cái gì đó tương tự như những gì tôi hiện đang làm. Ví dụ,
Octokit.netmột tập lệnh để thiết lập các biến môi trường cho các thử nghiệm tích hợp đang gọi API GitHub.
Nhưng họ chỉ cần một người dùng và một tổ chức, và tôi sẽ cần nhiều hơn nữa.

Có lẽ tôi không cần một giải pháp cho phép người đóng góp thực sự chạy tất cả các bài kiểm tra tích hợp.
Ví dụ: nếu ai đó muốn đóng góp cho hỗ trợ GitHub của dự án của tôi, anh ta chỉ cần có thể chạy thử nghiệm tích hợp GitHub.
Vì vậy, có lẽ tôi chỉ cần một cách lành mạnh để có thể chia các bài kiểm tra tích hợp của mình thành vô số "nhóm" (?) Và sau đó nói "và bây giờ thực hiện tất cả các bài kiểm tra thuộc nhóm 'Github'".

Câu trả lời:


2

Tôi nghĩ rằng thiết lập hiện tại của bạn là tốt, nhưng tôi sẽ thực hiện một vài điều chỉnh.

Để có thể thực hiện tất cả các thử nghiệm tích hợp, một người đóng góp tiềm năng sẽ tạo ra kho lưu trữ người dùng, tổ chức và thử nghiệm của riêng anh ta tại GitHub, Bitbucket, GitLab, .... và biết thêm bao nhiêu và thêm tất cả chúng vào các biến môi trường của anh ta phiên bản .bat.

Đúng, đó là sự thật, nhưng những người đóng góp không nhất thiết phải chạy tất cả các thử nghiệm tích hợp trước khi tạo PR cho dự án của bạn. Khi PR được tạo, CI sẽ chạy bộ thử nghiệm đầy đủ.

Điều phổ biến là có một bộ kiểm tra mà bằng cách nào đó không thể chạy dễ dàng. Đối với nhiều tổ chức, họ duy trì các bộ thử nghiệm mất nhiều ngày để chạy - do đó, các nhà phát triển phải chọn lọc chạy thử nghiệm dễ chạy và đẩy mã về phía trước để thử nghiệm nghiêm ngặt hơn. Tôi đang đề xuất cách tiếp cận tương tự.

Đối với những người đóng góp thường xuyên / đáng tin cậy, bạn có thể biến họ thành những người đóng góp thực sự cho dự án của bạn, điều này sẽ cho phép họ chạy CI trên chi nhánh của họ trước khi thực hiện PR.

Điều đó nói rằng, bạn không ngăn những người đóng góp chạy bộ thử nghiệm đầy đủ. Họ có thể cung cấp thông tin đăng nhập GitHub của riêng họ hoặc tạo tài khoản thử nghiệm của riêng họ và những người đóng góp thường xuyên có thể sẽ làm điều này.

Những điều chỉnh tôi đề nghị là:

Đầu tiên, thực hiện hầu hết các bài kiểm tra đơn vị bảo hiểm thử nghiệm của bạn. Chúng nên bao gồm tất cả các nhánh của cơ sở mã của bạn.

Thứ hai, viết các bài kiểm tra tích hợp trong đó điểm cuối bị chế giễu. Bạn thậm chí có thể giả định lớp vận chuyển của các API này và mô phỏng các luồng yêu cầu / phản hồi HTTP bằng cách bắt đầu dịch vụ GitHub Rest giả. Ví dụ: (bằng mã giả):

// Test failed authentication to GitHub
val server = new WebServer("localhost", 9453, { request =>
    return Response(401, "unauthenticated")
})
server.start()
val backupService = new GitHubBackupService("http://localhost:9453")
backupService.backup must throw UnauthenticatedException()
server.stop()

Các xét nghiệm này sẽ phức tạp hơn, nhưng sẽ cho phép bạn

  1. Kiểm tra mà không tạo tài khoản giả và kho
  2. Kiểm tra các điều kiện thất bại sẽ khó mô phỏng với GitHub thực. Ví dụ: phản hồi 502, thời gian chờ kết nối, cơ quan phản hồi bất thường / không thể nhìn thấy.

Thứ ba, vô hiệu hóa bất kỳ bài kiểm tra nào cần kiến ​​thức đặc biệt để chạy trong một bản dựng bình thường. Trong hầu hết các công cụ quản lý xây dựng, có một cách để tách các kiểm tra tích hợp hoặc kiểm tra thẻ và chạy có chọn lọc chúng. Người đóng góp có thể xây dựng và kiểm tra phần mềm mà không cần cấu hình trước. Bộ kiểm tra đầy đủ sẽ chạy sau mỗi lần xây dựng trong CI.

Cuối cùng, ghi lại các bài kiểm tra và cách chạy chúng trong tài liệu kiểm tra của bạn để những người đóng góp có thể chọn chạy chúng.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.