Cách thiết lập tích hợp liên tục với Buildbot trên Ubuntu 16.04
Buildbot là một hệ thống tích hợp liên tục dựa trên Python để tự động hóa các quy trình xây dựng, kiểm tra và phát hành phần mềm. Trong các hướng dẫn trước, ta đã cài đặt Buildbot , tạo các file Systemd Unit để cho phép hệ thống init của server quản lý các quy trình và cấu hình Nginx làm Reverse Proxy để hướng các yêu cầu trình duyệt được bảo mật SSL đến giao diện web của Buildbot.Trong hướng dẫn này, ta sẽ trình bày cách cài đặt hệ thống tích hợp liên tục để tự động kiểm tra các thay đổi mới đối với repository . Ta sẽ sử dụng một ứng dụng Node.js đơn giản để chứng minh quá trình thử nghiệm và cấu hình cần thiết. Để cách ly môi trường thử nghiệm của ta với server Buildbot, ta sẽ tạo một Docker image để chạy với quyền là nhân viên Buildbot của ta . Sau đó, ta sẽ cấu hình tổng thể Buildbot để xem repository GitHub để biết các thay đổi, tự động kiểm tra mỗi khi phát hiện các thay đổi mới.
Yêu cầu
Để làm theo hướng dẫn này, bạn cần :
- Một server Ubuntu 16.04 với ít nhất 1 GB RAM , được cấu hình với user
sudo
không phải root và firewall theo hướng dẫn cài đặt server ban đầu Ubuntu 16.04
Ngoài ra, bạn cần hoàn thành các hướng dẫn sau trên server :
- Cách cài đặt Buildbot trên Ubuntu 16.04
- Cách tạo file đơn vị Systemd cho Buildbot
- Cách cài đặt Nginx trên Ubuntu 16.04
- Cách bảo mật Nginx bằng Let's Encrypt trên Ubuntu 16.04 .
- Cách cấu hình Buildbot với SSL bằng Nginx Reverse Proxy
- Cách cài đặt và sử dụng Docker trên Ubuntu 16.04 : (chỉ có Bước 1 và 2)
Khi bạn đã hoàn thành các yêu cầu này, bạn đã sẵn sàng để bắt đầu.
Fork Kho lưu trữ mẫu trong GitHub
Trước khi bắt đầu cấu hình Buildbot, ta sẽ xem qua repository ví dụ mà ta sẽ sử dụng cho hướng dẫn này.
Trong trình duyệt web , hãy truy cập ứng dụng hello hapi trên GitHub mà ta sẽ sử dụng để trình diễn. Ứng dụng này là một chương trình “chào thế giới” đơn giản với một số bài kiểm tra đơn vị và tích hợp, được viết bằng hapi , một khuôn khổ web Node.js.
Vì ví dụ này được sử dụng để chứng minh nhiều hệ thống tích hợp liên tục, bạn có thể nhận thấy một số file được dùng để xác định đường ống cho các hệ thống khác. Đối với Buildbot, ta sẽ xác định các bước xây dựng trên server thay vì trong repository lưu trữ.
Sau đó, ta sẽ cài đặt webhook cho Buildbot trong repository lưu trữ của ta để các thay đổi sẽ tự động kích hoạt các thử nghiệm mới. Hiện tại, ta cần tạo nhánh repository của riêng mình.
Nhấp vào nút Fork ở góc trên bên phải của màn hình:
Nếu bạn là thành viên của tổ chức GitHub, bạn có thể được hỏi nơi bạn muốn chuyển repository :
Khi bạn chọn account hoặc tổ chức, một bản sao của repository sẽ được thêm vào account của bạn:
Bạn sẽ sử dụng URL cho fork của bạn trong cấu hình Buildbot. Bây giờ ta đã có một URL repository , ta có thể bắt đầu cấu hình Buildbot.
Cài đặt Docker cho Buildbot
Ta sẽ bắt đầu bằng cách cài đặt Docker để Buildbot sử dụng nó để thực hiện các bản dựng.Đầu tiên, ta cần cấu hình quyền truy cập giữa Docker và Buildbot. Sau đó, ta cần tạo một Docker image để sử dụng cho các containers của bạn .
Cấu hình quyền truy cập vào Docker cho Buildbot
Ta cần cho phép Buildbot và Docker giao tiếp ở một số cấp độ khác nhau.
Trước tiên, ta cần đảm bảo quy trình Buildbot có quyền truy cập vào daemon Docker. Ta có thể làm điều này bằng cách thêm user buildbot vào group Docker:
- sudo usermod -aG docker buildbot
Group mới này sẽ có sẵn cho Buildbot vào lần tiếp theo khởi động lại chính Buildbot mà ta sẽ thực hiện sau.
Ta cũng cần đảm bảo Buildbot biết cách giao tiếp với Docker. Vì Buildbot được viết bằng Python nên nó sử dụng gói docker-py
Python thay vì phát lệnh Docker trực tiếp.
Bạn có thể cài đặt docker-py
bằng lệnh :
- sudo -H pip install docker-py
Cuối cùng, ta cần mở quyền truy cập mạng từ containers đến hệ thống server và thế giới bên ngoài. Ta có thể làm điều này bằng cách cho phép một ngoại lệ cho giao diện docker0
trong firewall của ta .
Cho phép truy cập vào lưu lượng truy cập từ giao diện docker0
bằng lệnh :
- sudo ufw allow in on docker0
Buildbot và Docker bây giờ có thể giao tiếp với nhau một cách hiệu quả.
Tạo Docker image để sử dụng như một công nhân xây dựng
Tiếp theo, ta sẽ tạo một containers Docker để sử dụng như một nhân viên Buildbot để chạy các thử nghiệm của ta . Buildbot có thể khởi động động containers Docker để sử dụng làm công nhân, nhưng trước tiên các containers cần được xây dựng với một số thành phần công nhân Buildbot đi kèm.
May mắn là dự án Buildbot cung cấp hình ảnh nhân viên Buildbot cơ bản đã có tất cả các yêu cầu dành riêng cho Buildbot được cấu hình . Ta chỉ cần sử dụng hình ảnh này làm cơ sở và cài đặt các phụ thuộc bổ sung mà dự án của ta yêu cầu.
Trong trường hợp của ta , ứng dụng mẫu mà ta sẽ sử dụng là ứng dụng Node.js, vì vậy ta cần đảm bảo Node.js có sẵn trên hình ảnh.
Để xác định hình ảnh của ta , hãy tạo và mở một file có tên Dockerfile
trong folder chính của bạn:
- nano ~/Dockerfile
Trong file này, ta lấy hình ảnh của bạn dựa trên hình ảnh Buildbot worker bằng cách sử dụng FROM buildbot/buildbot-worker:master
. Sau đó, ta có thể chuyển sang user root
để cài đặt Node.js, rồi chuyển trở lại user buildbot
để chạy các lệnh thực tế:
FROM buildbot/buildbot-worker:master USER root RUN curl -sL https://deb.nodesource.com/setup_8.x | bash - RUN apt-get install -y nodejs USER buildbot
Lưu file khi bạn hoàn tất.
Khi ta có Dockerfile
, ta có thể xây dựng hình ảnh của bạn từ nó. Ta sẽ gọi hình ảnh npm-worker
để nói rõ về các phần phụ thuộc bổ sung mà ta đã cài đặt:
- docker build -t npm-worker - < ~/Dockerfile
Docker sẽ bắt đầu xây dựng hình ảnh của bạn dựa trên các lệnh mà ta đã nêu trong Dockerfile
. Nó sẽ kéo xuống hình ảnh cơ sở và các lớp phụ thuộc của nó, cài đặt Node.js, sau đó lưu môi trường kết quả vào một hình ảnh có tên là npm-worker
.
Cấu hình Buildbot Master
Bây giờ ta có một Docker image , ta có thể cấu hình Buildbot master để sử dụng nó.
Bởi vì ta đang xác định một quy trình xây dựng hoàn toàn mới và vì các tùy chỉnh của ta đối với cấu hình Chính cho đến thời điểm này là rất ít, nên ta sẽ bắt đầu cấu hình của bạn từ đầu. Để tránh mất thông tin hiện tại, ta sẽ chuyển file root sang file backup :
- sudo mv /home/buildbot/master/master.cfg /home/buildbot/master/master.cfg.bak
Hiển thị cấu hình của file backup để ta có thể sao chép một vài giá trị quan trọng để sử dụng trong cấu hình mới của bạn :
- sudo cat /home/buildbot/master/master.cfg.bak
Các phần quan trọng mà ta muốn chuyển sang cấu hình mới là thông tin xác thực và quyền của user . Tìm các phần cấu hình bắt đầu bằng c['www']['authz']
và c['www']['auth']
trong kết quả :
Output. . . c['www']['authz'] = util.Authz( allowRules = [ util.AnyEndpointMatcher(role="admins") ], roleMatchers = [ util.RolesFromUsername(roles=['admins'], usernames=['Sammy']) ] ) c['www']['auth'] = util.UserPasswordAuth({'Sammy': 'Password'}) . . .
Sao chép và lưu những dòng này ở đâu đó để bạn có thể tham khảo sau. Ta sẽ thêm những chi tiết này vào cấu hình chính Buildbot mới của bạn để duy trì cài đặt xác thực và user của ta .
Bây giờ, hãy tạo một file master.cfg
mới nơi ta có thể xác định lại hành vi của cá thể Buildbot của ta :
- sudo nano /home/buildbot/master/master.cfg
Ta sẽ xác cấu hình chính Buildbot mới của ta trong file này.
Cài đặt cấu hình dự án cơ bản
Tệp cấu hình Buildbot thực sự là một module Python, cung cấp tính linh hoạt cao với chi phí phức tạp.
Ta sẽ bắt đầu với một số cấu hình cơ bản. Dán các dòng sau vào file của bạn:
# -*- python -*- # ex: set filetype=python: from buildbot.plugins import * c = BuildmasterConfig = {} # Basic config c['buildbotNetUsageData'] = None c['title'] = "Hello Hapi" c['titleURL'] = "https://github.com/your_github_name/hello_hapi" c['buildbotURL'] = "https://buildmaster_domain_name/" c['protocols'] = {'pb': {'port': 9989}}
Phần đầu của file chứa một vài comment mà nhiều editor có thể diễn giải để áp dụng chính xác đánh dấu cú pháp. Sau đó, ta nhập mọi thứ từ gói buildbot.plugins
để ta có sẵn các công cụ để xây dựng cấu hình của bạn .
Cấu hình Buildbot tất cả được định nghĩa bởi một từ điển có tên BuildmasterConfig
, vì vậy ta đặt biến này thành một từ điển trống để bắt đầu. Ta tạo một biến ngắn gọn có tên c
được đặt cho cùng một từ điển này để giảm số lượng nhập cần thiết trong toàn bộ file .
Một số điều cần lưu ý trong cấu hình sau:
-
buildbotNetUsageData
được đặt thànhNone
. Thay đổi chuỗi này thành chuỗi"basic"
nếu bạn muốn báo cáo dữ liệu sử dụng cho nhà phát triển. -
title
vàtitle
titleURL
phản ánh tên dự án và repository GitHub. Sử dụng liên kết đến ngã ba của bạn . -
buildbotURL
được đặt thành domain được bảo mật SSL của chính Buildbot. Hãy nhớ bắt đầu bằnghttps://
và kết thúc bằng dấu gạch chéo/
. - Không giống như cấu hình cuối cùng của ta , định nghĩa
protocol
không liên kết với localhost. Ta cần cho phép các kết nối từ containers Docker quadocker0
mạng cầu nối Docker.
Cấu hình Docker Worker
Tiếp theo, ta cần xác định Docker worker của bạn . Buildbot sẽ sử dụng Docker để cung cấp nhân viên khi cần thiết. Để làm như vậy, nó cần biết cách kết nối với Docker và sử dụng hình ảnh nào.
Dán phần sau vào cuối file :
. . . # Workers c['workers'] = [] c['workers'].append(worker.DockerLatentWorker("npm-docker-worker", None, docker_host='unix://var/run/docker.sock', image='npm-worker', masterFQDN='buildmaster_domain_name'))
Dòng c['workers'] = []
thể hiện một quy ước cơ bản mà ta sẽ sử dụng khi đi qua cấu hình. Ta đặt một khóa trong từ điển cấu hình vào một danh sách trống. Sau đó, ta nối các phần tử vào danh sách để triển khai cấu hình thực tế. Điều này cho phép ta linh hoạt để thêm các yếu tố bổ sung sau này.
Để định nghĩa worker của ta , ta tạo và nối một instance worker.DockerLatentWorker
vào danh sách worker
. Ta đặt tên worker này là npm-docker-worker
để ta có thể tham khảo nó sau này trong cấu hình. Sau đó, ta đặt docker_host
thành vị trí socket của Docker và cung cấp tên của Docker image mà ta đã tạo ( npm-worker
trong trường hợp của ta ). Ta đặt masterFQDN
thành domain chính Buildbot của ta đảm bảo rằng containers có thể tiếp cận với chính dù cài đặt tên server nội bộ của server .
Cấu hình Bộ lập lịch
Tiếp theo, ta sẽ xác định một bộ lập lịch. Buildbot sử dụng bộ lập lịch để quyết định thời điểm và cách thức chạy các bản dựng dựa trên những thay đổi mà nó nhận được từ các nguồn thay đổi hoặc thay đổi móc ( ta sẽ cấu hình móc thay đổi sau).
Dán cấu hình sau vào cuối file :
. . . # Schedulers c['schedulers'] = [] c['schedulers'].append(schedulers.SingleBranchScheduler( name="hello_hapi", change_filter=util.ChangeFilter(project='your_github_name/hello_hapi', branch='master'), treeStableTimer=3, builderNames=["npm"]))
Ta sử dụng cùng một phương pháp thêm cấu hình của ta vào một danh sách trống ở đây. Trong trường hợp này, ta thêm một thể hiện schedulers.SingleBranchScheduler
. Điều này cho phép ta xem một nhánh duy nhất trên repository , giúp đơn giản hóa cấu hình.
Ta đặt tên cho bộ lập lịch biểu là “hello_hapi” để xác định chính xác nó. Sau đó, ta xác định một bộ lọc thay đổi. Nhiều tập hợp thay đổi khác nhau từ các nguồn khác nhau có thể được giao cho người lập lịch. Bộ lọc thay đổi xác định một bộ tiêu chí sẽ xác định xem liệu thay đổi được đề cập có nên được xử lý bởi bộ lập lịch cụ thể này hay không. Trong trường hợp của ta , ta lọc dựa trên tên của dự án, sẽ được báo cáo bởi webhook GitHub và chi nhánh mà ta muốn theo dõi.
Tiếp theo, ta đặt treeStableTimer
, xác định lượng thời gian để chờ các thay đổi bổ sung, thành 3 giây. Điều này giúp ngăn Buildbot xếp hàng đợi nhiều bản dựng nhỏ cho những thay đổi có liên quan chặt chẽ. Cuối cùng, ta xác định tên của trình xây dựng sẽ được sử dụng khi một thay đổi phù hợp với tiêu chí của ta ( ta sẽ xác định trình tạo này trong giây lát).
Cấu hình Nhà máy xây dựng cho Dự án Node.js
Tiếp theo, ta sẽ cấu hình một nhà máy xây dựng để xử lý các dự án Node.js. Nhà máy xây dựng chịu trách nhiệm xác định các bước cần thực hiện để xây dựng, hoặc trong trường hợp thử nghiệm của ta , một dự án. Nó thực hiện điều này bằng cách xác định một cá thể util.BuildFactory
và sau đó thêm các bước tuần tự cần được thực hiện.
Dán phần sau vào cuối file của bạn:
. . . # Build Factories npm_f = util.BuildFactory() npm_f.addStep(steps.GitHub(repourl='git://github.com/your_github_name/hello_hapi.git', mode='full', method='clobber')) npm_f.addStep(steps.ShellCommand(command=["npm", "install"])) npm_f.addStep(steps.ShellCommand(command=["npm", "test"]))
Đầu tiên, ta xác định một nhà máy xây dựng có tên là npm_f
. Bước đầu tiên mà ta thêm là một cá thể steps.GitHub
. Ở đây, ta đặt repository sẽ được kéo xuống trình tạo. Ta đặt mode
thành “đầy đủ” và method
thành “clobber” để dọn dẹp hoàn toàn repository của ta mỗi khi ta kéo mã mới.
Bước thứ hai và thứ ba ta thêm là các đối tượng steps.ShellCommand
, xác định các lệnh shell để chạy bên trong repository lưu trữ trong quá trình xây dựng. Trong trường hợp của ta , ta cần chạy npm install
để thu thập các phụ thuộc của dự án. Sau đó, ta cần chạy npm test
để chạy bộ thử nghiệm của bạn . Định nghĩa các lệnh dưới dạng danh sách ( ["npm", "install"]
) được khuyến khích trong hầu hết các trường hợp để ngăn shell áp dụng mở rộng không mong muốn trên các phần tử trong lệnh.
Cấu hình một người xây dựng
Khi ta có một nhà máy xây dựng với các bước được thêm vào, ta có thể cài đặt một nhà xây dựng. Trình tạo liên kết với nhiều phần tử mà ta đã xác định để xác định cách một bản dựng sẽ được thực thi.
Dán cấu hình sau vào cuối file :
. . . # Builders c['builders'] = [] c['builders'].append( util.BuilderConfig(name="npm", workernames=["npm-docker-worker"], factory=npm_f))
Ta thêm một đối tượng util.BuilderConfig
vào danh sách trình builders
. Lưu ý nhà máy xây dựng của ta được gọi là npm_f
, công nhân Docker của ta được gọi là npm_f
npm-docker-worker
và bộ lập lịch mà ta đã xác định sẽ chuyển các nhiệm vụ cho một công nhân có tên npm
. Trình tạo của ta xác định mối quan hệ giữa các phần tử này để những thay đổi từ trình lập lịch của ta sẽ khiến các bước của nhà máy xây dựng được thực thi trong Docker worker.
Cấu hình Database và Giao diện Web
Cuối cùng, ta có thể cấu hình cài đặt database và giao diện web. Không giống như nhiều mục trước đây, hai cài đặt này được định nghĩa là từ điển chứ không phải danh sách. Từ điển db
chỉ trỏ đến file state.sqlite
đã có trong folder /home/buildbot/master
của ta . Từ điển www
chứa một lượng lớn cấu hình bổ sung.
Dán phần sau vào cuối file của bạn. Thay thế thông tin xác thực bạn đã sao chép từ cấu hình chính Buildbot ban đầu cho khối xác thực bên dưới:
. . . # Database c['db'] = { 'db_url': "sqlite:///state.sqlite",} # Web Interface c['www'] = dict(port=8010, plugins=dict(waterfall_view={}, console_view={})) # Auth info copied from the original configuration c['www']['authz'] = util.Authz( allowRules = [ util.AnyEndpointMatcher(role="admins") ], roleMatchers = [ util.RolesFromUsername(roles=['admins'], usernames=['Sammy']) ] ) c['www']['auth'] = util.UserPasswordAuth({'Sammy': 'Password'}) # End of auth info copied from the original configuration # GitHub webhook receiver c['www']['change_hook_dialects'] = { 'github': { 'secret': 'your_secret_value', 'strict': True, } }
Sau khi xác định cài đặt database , ta tạo một từ điển www
bắt đầu bằng cách xác định cổng để nghe và một số chế độ xem để đưa vào giao diện user web. Tiếp theo, ta thêm các yêu cầu xác thực mà ta đã lấy từ file cấu hình Buildbot trước đó.
Cuối cùng, ta xác định một từ điển được gọi là change_hook_dialects
trong từ điển www
. Ta sử dụng điều này để xác định móc thay đổi GitHub, móc này sẽ lắng nghe các thông báo webhook từ GitHub. Chọn một passphrase (password bảo vệ) an toàn cho secret
của bạn, passphrase (password bảo vệ) này sẽ được GitHub sử dụng để xác thực các tin nhắn mà nó sẽ gửi.
Khi bạn hoàn tất, hãy lưu file .
Khởi động lại Buildbot Master để áp dụng cấu hình mới
Đến đây, ta đã cấu hình lại hoàn toàn quy trình chính của Buildbot. Ta cần khởi động lại quy trình tổng thể Buildbot để áp dụng các thay đổi .
Trước khi ta làm điều đó, điều quan trọng là phải kiểm tra file của ta để tìm lỗi cú pháp. Vì ta đã xây dựng lại cấu hình từ đầu, nên rất có thể ta đã mắc phải một số lỗi.
Kiểm tra cú pháp của file bằng lệnh :
- sudo buildbot checkconfig /home/buildbot/master
Lệnh sẽ báo cáo bất kỳ vấn đề nào mà nó tìm thấy. Nếu không tìm thấy lỗi nào, bạn sẽ nhận được một thông báo như sau:
OutputConfig file is good!
Nếu có lỗi , hãy cố gắng hiểu rõ hơn về lỗi sai bằng cách đọc kỹ thông báo lỗi. Mở lại file cấu hình để cố gắng khắc phục mọi sự cố.
Khi không còn bất kỳ lỗi nào, hãy khởi động lại dịch vụ chính Buildbot bằng lệnh :
- sudo systemctl restart buildbot-master
Kiểm tra xem thao tác có thành công hay không bằng lệnh :
- sudo systemctl status buildbot-master
Output● buildbot-master.service - BuildBot master service Loaded: loaded (/etc/systemd/system/buildbot-master.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2017-06-27 19:24:07 UTC; 2s ago Main PID: 8298 (buildbot) Tasks: 2 Memory: 51.7M CPU: 1.782s CGroup: /system.slice/buildbot-master.service └─8298 /usr/bin/python /usr/local/bin/buildbot start --nodaemon Jun 27 19:24:07 bb5 systemd[1]: Started BuildBot master service
Nếu dịch vụ có thể khởi động lại thành công, nó sẽ được đánh dấu là đang hoạt động.
Tạo một Webhook GitHub trong Kho lưu trữ Ví dụ
Bây giờ Buildbot được cấu hình với điểm cuối web để chấp nhận các bài đăng trên webhook trên GitHub, ta có thể cấu hình một webhook cho fork của bạn .
Trong trình duyệt web , chuyển đến nhánh của repository dự án mẫu:
https://github.com/your_github_user/hello_hapi
Nhấp vào tab Cài đặt để xem cài đặt dự án. Trong menu bên trái của trang cài đặt, nhấp vào Webhooks (GitHub có thể nhắc bạn nhập lại password của bạn trong quá trình này để xác nhận danh tính ):
Nhấp vào nút Thêm webhook ở bên phải để thêm webhook mới.
Trang sau sẽ chứa một biểu mẫu để xác định webhook của bạn. Trong trường URL tải trọng , hãy thêm URL cho điểm cuối móc thay đổi GitHub của dự án của bạn. Điều này được xây dựng bằng cách chỉ định giao thức https://
, theo sau là domain chính Buildbot của bạn, tiếp theo là /change_hook/github
.
Đặt loại Nội dung thành application/x-www-form-urlencoded
. Trong trường Bí mật , hãy nhập passphrase (password bảo vệ) bí mật mà bạn đã chọn trong file cấu hình chính Buildbot của bạn . Bạn có thể chọn trình kích hoạt “Chỉ sự kiện đẩy” và chọn hộp kiểm “Hoạt động”:
Khi bạn hoàn tất, hãy nhấp vào nút Thêm webhook .
Bạn sẽ được quay lại index webhooks của dự án, nơi webhook mới của bạn sẽ được hiển thị. Nếu bạn làm mới một vài lần, biểu tượng dấu kiểm màu xanh lục sẽ được hiển thị bên cạnh webhook của bạn cho biết rằng tin nhắn đã được truyền thành công:
Nếu bạn nhìn thấy dấu X màu đỏ, hãy nhấp lại vào webhook và sau đó cuộn xuống phần Giao hàng gần đây . Thông tin thêm về những gì đã xảy ra có sẵn nếu bạn nhấp vào giao hàng không thành công.
Kiểm tra Webhook
Bây giờ ta đã có webhook của bạn , ta có thể kiểm tra đảm bảo rằng khi ta áp dụng các thay đổi đối với repository của bạn , Buildbot sẽ được cảnh báo, kích hoạt bản dựng trong Docker và có thể thực thi thành công bộ thử nghiệm.
Trong trang chính của ngã ba GitHub của bạn, hãy nhấp vào nút Tạo file mới ở bên trái của nút “Sao chép hoặc download ” màu xanh lục:
Trên màn hình tiếp theo, hãy tạo một dummy_file
và điền vào một số văn bản:
Nhấp vào nút Commit file mới ở cuối trang khi bạn hoàn tất.
Tiếp theo, hãy truy cập giao diện web Buildbot của bạn và đăng nhập nếu bạn chưa được xác thực.
Tùy thuộc vào khoảng thời gian kể từ khi bạn commit dummy_file
vào repository của bạn , bạn có thể thấy một bản dựng đang tiến hành trông giống như sau:
Nếu bản dựng đã hoàn thành, nó sẽ nằm trong phần “bản dựng gần đây”:
Tên của trình tạo mà ta đã xác định, “npm”, được sử dụng để gắn nhãn cho công trình. Trong ví dụ này, ta cũng có thể thấy một lần chạy cũ hơn của trình tạo mẫu từ cấu hình Chính trước đó.
Dù tiến trình như thế nào, hãy nhấp vào liên kết tên người xây dựng và số bản dựng để truy cập trang chi tiết bản dựng. Chế độ xem này chứa thông tin về quá trình xây dựng đã được tiến hành. Mỗi bước mà ta đã thêm vào nhà máy xây dựng sẽ được hiển thị trong phần riêng của nó:
Nếu bạn nhấp vào một bước, kết quả từ lệnh sẽ được hiển thị.Điều này có thể giúp gỡ lỗi nếu có sự cố:
Trong kết quả kết quả ở trên, ta có thể xác minh Buildbot đã chạy ba thử nghiệm trong bộ thử nghiệm của ta thành công.
Nếu quá trình xây dựng không hoàn thành , một số khu vực khác mà bạn có thể cần kiểm tra là các tab khác trên trang chi tiết bản dựng cũng như file /home/buildbot/master/twistd.log
.
Điều chỉnh Dịch vụ Buildbot
Trước khi hoàn thành, ta nên thực hiện một số điều chỉnh đối với các dịch vụ Buildbot của bạn .
Hiện tại, ta có dịch vụ buildbot-worker
được xác định cho worker mà ta không còn sử dụng nữa (Docker worker của ta được khởi động tự động khi được yêu cầu). Ta nên dừng và vô hiệu hóa công nhân cũ của bạn .
Để dừng dịch vụ đang chạy và tắt dịch vụ bắt đầu khi server khởi động , hãy nhập:
- sudo systemctl stop buildbot-worker
- sudo systemctl disable buildbot-worker
OutputRemoved symlink /etc/systemd/system/buildbot-master.service.wants/buildbot-worker.service.
Kết quả trên cho biết rằng công nhân sẽ không được bắt đầu khởi động tiếp theo. Để xác minh dịch vụ không còn chạy nữa, hãy nhập:
- sudo systemctl status buildbot-worker
Output● buildbot-worker.service - BuildBot worker service Loaded: loaded (/etc/systemd/system/buildbot-worker.service; disabled; vendor preset: enabled) Active: inactive (dead) Jun 27 21:12:48 bb6 systemd[1]: Started BuildBot worker service. Jun 27 21:55:51 bb6 systemd[1]: Stopping BuildBot worker service... Jun 27 21:55:51 bb6 systemd[1]: Stopped BuildBot worker service.
Điều cuối cùng ta nên làm là cài đặt dependencies mềm giữa dịch vụ chính Buildbot của ta và daemon Docker. Vì dịch vụ chính Buildbot sẽ không thể cung cấp nhân công mới mà không có Docker, ta nên xác định yêu cầu này.
Mở buildbot-master.service
trong folder /etc/systemd/system
để điều chỉnh file dịch vụ:
- sudo nano /etc/systemd/system/buildbot-master.service
Trong phần [Unit]
, thêm docker.service
vào lệnh After
sau mục network.target
. Thêm một chỉ thị Wants
bổ sung cũng có tên là docker.service
. The Wants
cài đặt một phụ thuộc mềm trong After
chỉ thị After
cài đặt thứ tự bắt đầu:
[Unit] Description=BuildBot master service After=network.target docker.service Wants=docker.service [Service] User=buildbot Group=buildbot WorkingDirectory=/home/buildbot/master ExecStart=/usr/local/bin/buildbot start --nodaemon [Install] WantedBy=multi-user.target
Lưu file khi bạn hoàn tất.
Reload daemon systemd và dịch vụ để áp dụng cấu hình ngay lập tức:
- sudo systemctl daemon-reload
- sudo systemctl restart buildbot-master
Quy trình tổng thể Buildbot bây giờ sẽ được bắt đầu sau khi có Docker.
Kết luận
Trong hướng dẫn này, ta đã cấu hình Buildbot để lắng nghe các thay đổi đối với repository GitHub bằng cách sử dụng webhooks. Khi nhận được thay đổi, Buildbot khởi động containers dựa trên Docker image tùy chỉnh để kiểm tra commit mới. Docker image chứa một version Buildbot worker cũng như các phụ thuộc cần thiết để kiểm tra mã dự án của ta . Điều này cho phép Buildbot khởi động động các công nhân Buildbot khi cần thiết khi nào có thay đổi đối với repository .
Các tin liên quan
Cách thiết lập đường ống tích hợp liên tục với Drone trên Ubuntu 16.042017-06-28
Cách thiết lập đường ống tích hợp liên tục trong Jenkins trên Ubuntu 16.04
2017-06-16
Cách cài đặt và cấu hình Drone trên Ubuntu 16.04
2017-06-14
Cách giám sát cảnh báo Zabbix với Alerta trên Ubuntu 16.04
2017-06-13
Cách cài đặt và cấu hình Zabbix để giám sát an toàn server từ xa trên Ubuntu 16.04
2017-06-08
how-to-config-an-orientdb-cluster-on-ubuntu-16-04
2017-06-02
Cách cài đặt và cấu hình OpenLDAP và phpLDAPadmin trên Ubuntu 16.04
2017-06-01
Cách bật SFTP mà không cần truy cập Shell trên Ubuntu 16.04
2017-05-31
Cách tạo Go Executables cho nhiều nền tảng trên Ubuntu 16.04
2017-05-30
Cách cài đặt Concourse CI trên Ubuntu 16.04
2017-05-26