TOC

Как самостоятельно размещать обзор ниндзя в DigitalOcean с помощью Docker и CoreOS

Вступление

Проверка кода стала неотъемлемой частью современного процесса разработки программного обеспечения. С появлением распределенных систем контроля версий, и особенно с момента появления GitHub, модель pull-review-review-merge стала популярной среди сообщества разработчиков программного обеспечения. Однако встроенная в GitHub система просмотра запросов на выборку оставляет желать лучшего. В результате для улучшения процесса существует множество сторонних инструментов для проверки кода, которые интегрируются с GitHub. ReviewNinja является одним из таких инструментов.

ReviewNinja добавляет несколько функций поверх ванильного интерфейса проверки запросов на вытягивание GitHub. Это дает нам возможность явно подписывать запрос на включение, задавая «звезды ниндзя», так что больше нет необходимости в комментариях типа:shipit:,LGTM или других популярных условных обозначениях. И вы можете установить политики для блокировки слияния, если пул-реквест не подписан по крайней мере двумя членами команды, или если кто-то добавляет комментарии вроде!fix к пул реквесту.

ReviewNinja разработан и открытыми источниками SAP. У него естьhosted version, но мы можем развернуть его на наших собственных серверах и использовать для наших частных репозиториев GitHub.

В этом руководстве вы развернете экземпляр ReviewNinja в DigitalOcean, используяDocker иCoreOS. В производственном экземпляре ReviewNinja есть несколько движущихся частей, поэтому мы будем использоватьdocker-machine для создания удаленного хоста Docker и управления им, аdocker-compose - для описания, сборки и развертывания нашего стека. Мы будем использовать CoreOS для хоста Docker, который является минимальным дистрибутивом Linux, предназначенным для облачных развертываний. При новой установке CoreOS работает толькоsystemd и демон Docker, поэтому для наших приложений доступно больше ресурсов.

Предпосылки

Для завершения этого урока вам понадобится:

  • Docker,docker-machine иdocker-compose установлены на вашем локальном компьютере, поэтому вы можете создать образ приложения, который мы развернем. Вы можете следить заthe official installation documentation для Docker, чтобы настроить эти инструменты. Иdocker-machine, иdocker-compose устанавливаются автоматически вместе с приложением Docker в OSX и Windows, или вы можете установить их вручную, используя следующие ссылки:

  • Git установлен на вашем локальном компьютере, поэтому вы можете клонировать репозиторий ReviewNinja для создания контейнера. Следуйтеofficial Git installation documentation, если вам нужно выполнить это предварительное условие.

  • Токен доступа DigitalOcean с доступом для чтения и записи, который вы можете создать, посетив страницуApplications & API. Скопируйте этот токен, так как вам нужно будет использовать его сdocker-machine для создания хостов.

  • Одна дроплет CoreOS объемом 1 ГБ, которую мы настроим с помощьюdocker-machine в этом руководстве.

  • АккаунтGitHub.

[[step-1 -—- create-and-activating-a-coreos-based-docker-host]] == Шаг 1. Создание и активация хоста Docker на базе CoreOS

Давайте создадим инфраструктуру для нашего развертывания. Инструментdocker-machine позволяет вам предоставлять удаленные машины в качестве хостов Docker и управлять ими с вашего локального компьютера. Он предоставляет драйверы для многих популярных облачных провайдеров, включая DigitalOcean. Мы будем использоватьdocker-machine для создания капли CoreOS для нашего хоста Docker.

Переключитесь на свой терминал и введите следующую команду, используя свой токен доступа DigitalOcean: 

docker-machine create --driver=digitalocean \
--digitalocean-access-token=DIGITAL_OCEAN_ACCESS_TOKEN \
--digitalocean-image=coreos-stable \
--digitalocean-region=nyc3 \
--digitalocean-size=1GB \
--digitalocean-ssh-user=core \
reviewninja

Мы говоримdocker-machine создать каплю с именемreviewninja в центре обработки данныхNYC3, используя изображениеcoreos-stable с1GB памяти. Обратите внимание, что мы указываем--ssh-user=core, потому что пользователь по умолчанию в установке CoreOS -core.

Когда вы выполните эту команду, вы увидите следующий вывод: 

OutputRunning pre-create checks...
Creating machine...
(reviewninja) Creating SSH key...
(reviewninja) Creating Digital Ocean droplet...
(reviewninja) Waiting for IP address to be assigned to the Droplet...
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Detecting the provisioner...
Provisioning with coreOS...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Checking connection to Docker...
Docker is up and running!
To see how to connect your Docker Client to the Docker Engine running on this virtual machine, run: docker-machine env reviewninja

Посмотрим, распознает ли эту новую каплюdocker-machine. Запустите команду: 

docker-machine ls

Вы увидите следующий вывод, указывающий, что хост Dockerreviewminja работает на удаленном IP-адресе с помощью драйвераdigitalocean: 

OutputNAME          ACTIVE   DRIVER         STATE     URL                          SWARM   DOCKER    ERRORS
reviewninja            digitalocean   Running   tcp://your_ip_address:2376            v1.10.3

Когда мы создали хост Docker, последняя строка вывода говорила нам, что делать дальше. Он сказал: 

OutputTo see how to connect your Docker Client to the Docker Engine running on this virtual machine, run: docker-machine env reviewninja

Итак, давайте запустим эту команду: 

docker-machine env reviewninja

Вы увидите это сообщение: 

Outputexport DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://your_server_ip:2376"
export DOCKER_CERT_PATH="/home/kevin/.docker/machine/machines/reviewninja"
export DOCKER_MACHINE_NAME="reviewninja"
# Run this command to configure your shell:
# eval $(docker-machine env reviewninja)

Так что здесь происходит? В архитектуре Docker используется модель клиент-сервер. Клиент Docker может общаться через сокет Unix или через TCP. Обычно наш клиент Docker общается с механизмом Docker, установленным локально через сокет Unix. Однако есть переменные окружения, которые вы можете настроить, чтобы сообщить клиенту Docker об обмене данными с хостом Docker по TCP. Вывод, который вы видите, представляет собой серию команд оболочки для установки переменных среды, которые делают именно это.

Последняя часть говорит: 

Output# Run this command to configure your shell:
# eval $(docker-machine env reviewninja)

Когда вы запускаете эту команду, вы указываете оболочке выполнить эти команды, которые устанавливают переменные среды, которые будут использоваться для последующих командdocker.

Так что продолжайте и выполните эту команду в вашей оболочке: 

eval $(docker-machine env reviewninja)

Теперь, если вы выполнитеdocker info, вы увидите информацию об удаленном демоне Docker, а не о локальном демоне Docker: 

docker info

Вывод этой команды будет выглядеть так: 

OutputContainers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 1.10.3
 [...]
Labels:
 provider=digitalocean

[.Примечание]##

Note: при выполнении командdocker может появиться следующая ошибка: 

Error response from daemon: client is newer than server (client API version: 1.24, server API version: 1.22)

Это означает, что используемая вами версия клиента Docker несовместима с версией сервера. Чтобы исправить это, установите для переменной средыDOCKER_API_VERSION ту же версию, что и на сервере. Например, если сервер хочет версию 1.22, выполните следующую команду: 

export DOCKER_API_VERSION=1.22

Затем попробуйте снова запустить команды Docker.

Наш удаленный хост Docker теперь настроен и доступен через Docker. Прежде чем мы сможем создать контейнер ReviewNinja, нам нужно поработать с GitHub.

[[step-2 -—- register-a-github-oauth-application]] == Шаг 2. Зарегистрируйте приложение GitHub OAuth

ReviewNinja должен использовать API GitHub для доступа к вашим репозиториям, поэтому мы зарегистрируем нашу установку ReviewNinja как приложение GitHub OAuth.

Для начала нам нужно узнать IP-адрес нашего сервера. Для этого мы можем использовать командуdocker-machine: 

docker-machine ip reviewninja

Запишите IP-адрес, отображаемый этой командой. Затем войдите в свою учетную запись GitHub, перейдите кSettings → OAuth applications → Developer applications и нажмите кнопкуRegister a new application.

New GitHub OAuth application form

Когда вы получите форму для нового заявления, введите следующую информацию:

  1. УстановитеName наreview-ninja.

  2. УстановитеHomepage URL наhttp://your_ip_address.

  3. УстановитеAuthorization Callback URL наhttp://your_ip_address/auth/GitHub/callback.

Затем нажмите кнопкуRegister application, чтобы сохранить изменения и создать приложение. Это отобразит вновь созданное приложение на экране.

Сохраните значения дляClient ID иClient Secret в безопасном месте; вы скоро добавите их в конфигурацию приложения ReviewNinja.

GitHub app client id and secret

Теперь, когда у вас есть ключи, давайте приступим к созданию нашего экземпляра ReviewNinja.

[[step-3 -—- created-the-reviewninja-docker-container]] == Шаг 3. Создание контейнера Docker ReviewNinja

ReviewNinja - это приложение Node.js, которое опирается на уровень хранения, поддерживаемый MongoDB. И поскольку мы помещаем это в производственную среду, мы разместим приложение Node.js за прокси-сервером, чтобы сервер приложений не был напрямую подключен к Интернету. Мы будем использовать Nginx для этой цели. Это много для настройки, поэтому мы будем использоватьdocker-compose для декларативного развертывания нескольких связанных контейнеров. Мы определяем нужную конфигурацию, а затем используем инструментdocker-compose для создания контейнеров со всеми указанными средами выполнения.

Во-первых, нам нужно получить исходный код ReviewNinja. Клонировать исходный код на вашем локальном компьютере с помощью Git: 

git clone https://github.com/reviewninja/review.ninja.git

Затем перейдите в папку проекта: 

cd review.ninja

Этот репозиторий содержитDockerfile, который сообщает Docker, как создать образ приложения ReviewNinja. Если вы откроете этот файл в своем любимом текстовом редакторе, вы увидите следующее содержимое:

Dockerfile 

FROM node:0.12.2

COPY . /app

RUN npm install -g bower
RUN cd /app; npm install; bower install --allow-root;

WORKDIR /app

VOLUME ["/certs"]

EXPOSE 5000

CMD ["node", "/app/app.js"]

Этот файл указывает версию Node.js, которую будет использовать это приложение. Затем он копирует все файлы из текущей папки в папкуapp и устанавливает все зависимости приложения. Затем он открывает порт5000 и запускает приложение. Для более подробного ознакомления с Dockerfiles см.this tutorial.

Dockerfile описывает контейнер приложения ReviewNinja, но мы можем описать компоненты нашего стека, включая MongoDB и прокси-сервер Nginx, используя файл с именемdocker-compose.yml, который является файломYAML, популярным форматом для файлы конфигурации.

В клонированном вами репозитории есть файл с именемdocker-compose-example.yml, но мы собираемся написать собственный файл с нуля, потому что пример не соответствует нашим требованиям.

Во-первых, давайте определим хранилище для нашего стека. Создайте файлdocker-compose.yml и введите следующую конфигурацию:

docker-compose.yml

version: "2"
services:
    db:
        image: mongo
        volumes:
            - /data:/data/db

Службаdb использует официальныйMongoDB image в Docker Hub, центральном репозитории образов Docker. По своей конструкции контейнеры Docker теряют свои состояния времени выполнения, когда они останавливаются и удаляются. Это нормально для службыweb, поскольку она не имеет состояния. Для нашей службыdb нам необходимо сохранить данные на диске, чтобы мы не потеряли все данные проверки кода, если остановим или перезапустим службу. Здесь на помощь приходитvolumes. Во время выполнения демон Docker может запустить контейнер, который сопоставляет тома в контейнере с каталогами на хосте.

В нашей конфигурации мы указали следующее:

docker-compose.yml

        volumes:
            - /data:/data/db

Это сопоставляет папку/data хост-компьютера с/data/db в контейнере, который, как оказалось, является папкой, в которую MongoDB настроена для записи внутри контейнера. При создании этого сопоставления изменения, внесенные приложением, сохраняются на хост-компьютере в папке/data, а не в контейнере.

Далее мы определяем контейнер приложения ReviewNinja. Добавьте это в файлdocker-compose.yml после существующей конфигурации:

docker-compose.yml

services:
    db:
    [...]

    web:
        build: .
        working_dir: /app/
        links:
            - db
        environment:
            MONGODB: mongodb://db/reviewninja
            GITHUB_CLIENT: YOUR_GITHUB_APP_ID
            GITHUB_SECRET: YOUR_GITHUB_APP_SECRET

[.note] #Note: Убедитесь, чтоweb выровнен по вертикали с определением службыdb, которое вы ранее определили как файлы YAML, и очень требовательны к отступам.
#

Мы используемbuild ., который сообщаетdocker-compose, что изображение должно быть построено изDockerfile, которое мы только что исследовали в текущей папке. Затем мы объявляем ссылку на изображениеdb, поэтому внутри контейнераweb имяdb будет преобразовано в IP-адрес контейнераdb. Это обеспечивает элементарный механизм обнаружения сервисов; нам не нужно заранее знать IP-адрес контейнераdb и жестко его кодировать или передавать через переменную среды. Затем мы используем эту ссылку для определения переменной окруженияMONGODB, используяmongodb://db/reviewninja в качестве значения.

ЗаполнитеGITHUB_CLIENT иGITHUB_SECRET идентификатором клиента и секретом для созданного вами приложения GitHub. Приложение ReviewNinja будет читать эти переменные среды во время выполнения.

Наконец, давайте определим службу балансировки нагрузки, которая будет перенаправлять запросы с порта80 на порт, который использует наше приложение Node.js. Добавьте эту конфигурацию в файл, выровняв ее по вертикали с объявлением службыweb, которое вы только что создали:

docker-compose.yml

services:
    web:
    [...]
    nginx:
        image: nginx
        ports:
            - "80:80"
        volumes:
            - ./reviewninja.conf:/etc/nginx/conf.d/default
        command: /bin/bash -c "echo -e 'upstream backend { server web:5000; }\nserver { listen 80; location / { proxy_pass http://backend; }}' > /etc/nginx/conf.d/default.conf && nginx -g 'daemon off;'"
        links:
            - web

Мы используемofficial Nginx image из Docker Hub и объявляем сопоставление портов80:80, которое связывает порт80 на хосте с портом80 в контейнере. Затем мы создаем сопоставление томов, в котором хранится файл конфигурации Nginx вне контейнера, и объявляем связь контейнера с контейнеромapp, чтобы мы могли найти его по имени и прокси-запросы к нему.

Объявлениеcommand довольно длинное, поэтому давайте разберем его. На самом деле он запускает две команды в одной строке. Первая команда -echo -e ... > /etc/nginx/conf.d/default.conf, которая создает файл конфигурации Nginx для ReviewNinja, который выглядит следующим образом:

default.conf

upstream backend {
    server web:5000;
}

server {
    listen       80;

    location / {
        proxy_pass http://backend;
    }
}

Это определяетbackend в восходящем направлении и указывает наweb:5000. Значениеweb берется из файлаdocker-compose.yml в разделеlinks, а порт5000 - это порт, который сервер Node.js использует в контейнереweb. Затем мы объявляем, что наш сервер Nginx будет работать на порту80 в контейнере и должен передавать все запросы наbackend, наш сервер приложений.

Вторая часть командыnginx -g 'daemon off' - это команда, запускающая серверный процесс Nginx в контейнере. Нам нужно указатьdaemon off, потому что Nginx по умолчанию работает в режиме демона, отделяясь от запущенного процесса. Docker рассматривает любую программу, отсоединенную от точки входа в контейнер, как «завершенную» и завершает работу контейнера, пожиная все процессы. Как правило, любой процесс, выполняющийся внутри контейнера Docker, должен выполняться на переднем плане.

Вот весь файлdocker-compose.yml, на тот случай, если вы захотите дважды проверить свою конфигурацию, прежде чем двигаться дальше:

docker-compose.yml

version: "2"
services:
    db:
        image: mongo
        volumes:
            - /data:/data/db
    web:
        build: .
        working_dir: /app/
        links:
            - db
        environment:
            MONGODB: mongodb://db/reviewninja
            GITHUB_CLIENT: YOUR_GITHUB_APP_ID
            GITHUB_SECRET: YOUR_GITHUB_APP_SECRET
    nginx:
        image: nginx
        ports:
            - "80:80"
        volumes:
            - ./reviewninja.conf:/etc/nginx/conf.d/default
        command: /bin/bash -c "echo -e 'upstream backend { server web:5000; }\nserver { listen 80; location / { proxy_pass http://backend; }}' > /etc/nginx/conf.d/default.conf && nginx -g 'daemon off;'"
        links:
            - web

Взгляните наdocker-compose documentation, если вы хотите больше узнать о синтаксисе и параметрах дляdocker-compose.yml.

Это заботится о нашей конфигурации для этого приложения. Сохраните файлdocker-compose.yml; пришло время развернуть это приложение.

[[step-4 -—- build-and-deploy-the-container]] == Шаг 4. Сборка и развертывание контейнеров

Мы настроилиdocker-compose для развертывания нашего приложения ReviewNinja, экземпляра MongoDB для хранения данных и прокси-сервера Nginx. Прежде чем развертывать эти контейнеры, давайте проверим, что машина Dockerreviewninja по-прежнему активна: 

docker-machine active

Тебе следует увидеть: 

Outputreviewninja

Если вы не видите этот вывод, обязательно запустите 

eval $(docker-machine env reviewninja)

еще раз, чтобы убедиться в правильности настроек среды. Тогда попробуйте еще раз.

Убедившись, что у вас есть активная машина, используйтеdocker-compose для создания стека: 

docker-compose build

Этот процесс может занять очень много времени, так как он загружает и настраивает все зависимости для приложения ReviewNinja на хосте Docker. Вы увидите следующий вывод: 

Outputdb uses an image, skipping
Building web
Step 1 : FROM node:0.12.2
0.12.2: Pulling from library/node
[...]
Successfully built 106a1992d538

После завершения процесса сборки убедитесь, что у вас есть успешный образ: 

docker images

Вы увидите следующий результат, указывающий, что изображениеreviewninja_web было успешно создано: 

OutputREPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
reviewninja_web     latest              106a1992d538        3 minutes ago       946.6 MB

Теперь мы можем запустить нашу базу данных, наше приложение ReviewNinja и наш прокси Nginx на нашем удаленном сервере с помощью одной команды: 

docker-compose up -d

Это вызывает все контейнеры, которые мы определили в файлеdocker-compose. Мы используем-d (для «отсоединения»), поэтому все контейнеры работают в фоновом режиме, и наш терминал снова находится под нашим контролем. 

OutputCreating network "reviewninja_default" with the default driver
Pulling db (mongo:latest)...
latest: Pulling from library/mongo
[...]
Digest: sha256:d3f19457c816bb91c5639e3b1b50f67370e3b3a58b812d73446d7b966469c65e
Status: Downloaded newer image for mongo:latest
Creating reviewninja_db_1
Creating reviewninja_web_1
Creating reviewninja_nginx_1

Давайте проверим, что контейнеры работают и работают. Выполните следующую команду: 

docker ps

Вы увидите вывод, который выглядит следующим образом: 

OutputCONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                         NAMES
29f8e6f770d3        nginx               "nginx -g 'daemon off"   43 seconds ago      Up 41 seconds       0.0.0.0:80->80/tcp, 443/tcp   reviewninja_nginx_1
164564dd450a        reviewninja_web     "node /app/app.js"       45 seconds ago      Up 43 seconds       5000/tcp                      reviewninja_web_1
7cd9d03eb3b9        mongo               "/entrypoint.sh mongo"   46 seconds ago      Up 44 seconds       27017/tcp                     reviewninja_db_1

Мы также хотим убедиться, что сервисы работают правильно. Для этого мы используем командуdocker logs, чтобы увидеть вывод контейнера. Давайте проверим журналы для веб-приложения ReviewNinja. Мы можем ссылаться на контейнер либо по его идентификатору, указанному в столбцеCONTAINER ID в предыдущем выводе, либо по его имени. В нашем случае это имяreviewninja_web_1, поэтому давайте посмотрим журналы для этого контейнера: 

docker logs reviewninja_web_1

Вы увидите выходные данные из приложения ReviewNinja, указывающие, что оно прослушивает соединения: 

OutputIn server/app.js
checking configs
✓ configs seem ok
Host:        http://localhost:5000
GitHub:      https://GitHub.com
GitHub-Api:  https://api.GitHub.com
bootstrap certificates
bootstrap static files
apply migrations
[...]
bootstrap mongoose
[...]
bootstrap passport
[...]
bootstrap controller
[...]
bootstrap api
[...]
bootstrap webhooks
[...]
bootstrap monkey patch

✓ bootstrapped, app listening on localhost:5000

Вывод указывает, что ReviewNinja прослушивает порт5000.

Чтобы получить к нему доступ из Интернета, нам потребуется использовать IP-адрес нашего хоста Docker, который является нашим сервером CoreOS. Если вы забыли IP-адрес своего сервера, используйтеdocker-machine, чтобы узнать. 

docker-machine ip reviewninja

В браузере выберитеhttp://your_server_ip, и вас встретит ниндзя:

ReviewNinja home page

Наконец, мы готовы использовать приложение с нашим собственным кодом.

[[step-5 -—- using-reviewninja-with-a-repository]] == Шаг 5. Использование ReviewNinja с репозиторием

Давайте попробуем наш новый экземпляр ReviewNinja в тестовом репозитории. Мы предоставим обратную связь по запросу извлечения, решим проблему, примем изменения и объединим запрос извлечения.

Сначала нам нужно разрешить приложению Review Ninja получить доступ к вашей учетной записи GitHub. НажмитеSign In, и вы будете перенаправлены на GitHub для входа. Вам будет предложено разрешить ReviewNinja доступ к вашей учетной записи GitHub:

Grant app permissions through GitHub

Как только вы авторизуете приложение, вы попадете в основной интерфейс ReviewNinja. Если у вас есть частные репозитории, которые вы хотели бы использовать в ReviewNinja, вы можете щелкнуть ссылкуEnable private repos:

Enabling access to private repositories

Затем вы будете перенаправлены на GitHub, чтобы пересмотреть свое разрешение приложения ReviewNinja, чтобы включить доступ к вашим личным репозиториям:

Authorizing private repositories

После того, как вы предоставили ReviewNinja доступ, который хотите получить, вы можете добавить репозиторий, чтобы вы могли использовать ReviewNinja для вашего рабочего процесса запроса на извлечение. Когда вы впервые используете ReviewNinja, у вас есть возможность добавить образец репозиторияReviewNinja-Welcome:

Adding a sample repository

Создайте этот репозиторий образцов, чтобы мы могли пройтись по некоторым основным функциям ReviewNinja. Это создает репозиторий на Github под вашей учетной записью и добавляет его в ReviewNinja.

Репозиторий примеров содержит файлReadMe.md, который должен описывать некоторые особенности процесса проверки кода ReviewNinja. В репозиторииReviewNinja-Welcome уже открыт запрос на вытягивание из веткиyour_github_username-patch-1, в которой есть обновленная копия файлаReadMe.md. Название ветки будет зависеть от вашего имени пользователя.

Pull Requests View

Нажмите на эту ветку, и вы увидите основной интерфейс обзора кода, где вы можете просматривать различия и добавлять комментарии. Вы также увидите окно состояния запроса на извлечение, в котором указано состояние запроса на получение и нерешенных проблем.

Pull Request status box

КнопкаMerge pull request сейчас желтая, потому что статус запроса на вытягивание «ожидает». Статус будет меняться в зависимости от состояния, которое вы можете настроить, нажав на кнопку передач. По умолчанию требуется, чтобы по крайней мере 1 звезда ниндзя для кнопки стала зеленой.

Мы увидим это в действии позже, но сейчас давайте добавим комментарий к строке. Нажмите на строку кода, которая говорит 

+ convenience we also have a dropdown menu to add these comments

Add a line comment

Давайте будем немного педантичны и предложим заменить словоdropdown наdrop-down. Добавьте комментарий, используя поле для комментариев в правой части экрана, и отметьте это как проблему блокировки, добавив!fix к вашему комментарию, как показано на следующем рисунке:

Flag a line

Отмеченный комментарий будет рассматриваться как «проблема» в запросе на получение, который необходимо разрешить автору запроса на выборку, прежде чем ReviewNinja разрешит его объединение.

Обновите страницу, и теперь вы увидите новую проблему, указанную над кнопкойMerge pull request:

Our problem

Давайте исправим эту проблему. На вашем локальном компьютере используйте Git для клонирования репозитория: 

git clone [email protected]:your_github_username/ReviewNinja-Welcome.git
cd ReviewNinja-Welcome

Тогда проверьте ветку, которая нуждается в работе: 

git checkout your_github_username-patch-1

ОткройтеReadMe.md в вашем любимом текстовом редакторе и измените строку так, чтобы она говорилаdrop-down вместоdropdown: 

label ReadMe.md
To add a flag simply leave a comment with your desired flag. For
convenience we also have a drop-down menu to add these comments
automatically.

Сохраните файл в вашем редакторе, затем добавьте и зафиксируйте ваши изменения: 

git add ReadMe.md
git commit -m "Address code review feedback"

Затем отправьте изменения в ветку на Github: 

git push origin your_github_username-patch-1

Теперь обновите интерфейс ReviewNinja в вашем браузере. Вы увидите, что код обновлен, и если вы снова щелкните строку, вы можете ответить на существующий комментарий с помощью!fixed или!resolved, как показано на следующем рисунке:

Mark a problem as resolved

Наконец, теперь, когда мы удовлетворены запросом на выдачу, давайте дадим ему звезду ниндзя в качестве официального подтверждения. Нажмите кнопкуAdd ninja star:

ninja star

Затем обновите браузер и обратите внимание, что статус запроса на вытягивание обновлен до «успешно», а кнопкаMerge pull request зеленая:

Ready for merge

Вы можете настроить условие успешного выполнения запроса на извлечение, нажав на кнопку передачи:

Customize

Идем дальше и нажимаем «Merge pull request». После перезагрузки страницы (возможно, вам придется обновить ее вручную), вы увидите, что статус запроса извлечения изменяется на «Объединен».

Merged

Одна вещь, о которой следует помнить: pull-запросы ReviewNinjaare GitHub pull-запросы и наоборот. Комментарии, сделанные на ReviewNinja, будут автоматически отражены на странице запроса GitHub и наоборот. Запросы на извлечение, объединенные через ReviewNinja, также будут отражены на GitHub:

GitHub pull requests are synced

Эта двунаправленная синхронизация будет очень полезна для команд, которые хотят постепенно перейти на ReviewNinja для проверки кода.

Заключение

В этом руководстве вы использовали Docker,docker-machine иdocker-compose для развертывания ReviewNinja, многоуровневого веб-приложения. Вы узнали, как создать образ Docker из существующего приложения и как определить и развернуть всю инфраструктуру, не выходя из локального терминала.

Вы также узнали о некоторых мощных функциях ReviewNinja и о том, как использовать эти функции, чтобы добавить некоторый элемент управления рабочим процессом в процесс получения запросов GitHub.

Приятного просмотра кода!

Related