Skip to main content
Мы публикуем частые обновления нашей документации, и перевод этой страницы, возможно, еще выполняется. Актуальные сведения см. в документации на английском языке.
All products
Приложения

Настройка среды разработки для создания приложения GitHub

В этой статье

Изучите основы расширения и создания новых GitHub Apps.

Введение

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

К концу этого руководства вы зарегистрируете приложение GitHub и настроите веб-сервер для получения событий веб-перехватчика. Вы узнаете, как использовать средство Smee для захвата полезных данных веб-перехватчика и перенаправления их в локальную среду разработки. Приложение-шаблон, которое вы настроите в этом разделе, не будет делать ничего особенного, но будет служить платформой, которую можно использовать для написания кода приложения с помощью API или выполнения инструкций из других кратких руководств.

После завершения этого проекта вы узнаете, как пройти проверку подлинности для приложения GitHub и установки, а также чем эти способы проверки подлинности отличаются.

Ниже приведены действия по настройке шаблона приложения GitHub:

  1. Запуск нового канала Smee
  2. Регистрация нового приложения в GitHub Apps
  3. Сохранение закрытого ключа и идентификатора приложения
  4. Подготовка среды выполнения
  5. Проверка кода шаблона приложения GitHub
  6. Запуск сервера
  7. Установка приложения в учетной записи

Примечание. В этом руководстве демонстрируется процесс разработки приложений с использованием языка программирования Ruby. Однако существуют и другие способы применения Octokit. Если вы предпочитаете JavaScript, то для разработки приложений GitHub можно использовать Probot и Node.js.

Предварительные требования

Могут быть полезны базовые знания в следующих областях:

Но вы можете работать, имея любой уровень опыта. Мы будем ссылаться на необходимую информацию на этом пути!

Перед началом работы необходимо клонировать репозиторий с помощью кода шаблона, используемого для выполнения этого краткого руководства. Откройте приложение терминала и найдите каталог, в котором вы хотите сохранить код. Выполните следующую команду, чтобы клонировать репозиторий шаблона приложения GitHub:

$ git clone https://github.com/github-developer/github-app-template.git

Шаг 1. Запуск нового канала Smee

Чтобы помочь GitHub отправлять веб-перехватчики на локальный компьютер без предоставления доступа из Интернета, можно использовать средство Smee. Сначала перейдите по адресу https://smee.io и нажмите кнопку Запустить новый канал. Если вы уже уверенно пользуетесь другими средствами, которые предоставляют локальный компьютер из Интернете, как ngrok или localtunnel, то можете использовать их.

Запуск нового канала Smee создает уникальный домен, в котором GitHub может отправлять полезные данные веб-перехватчика. Smee вызывает URL-адрес этого уникального домена как URL-адрес прокси-сервера веб-перехватчика. Вам потребуется знать этот URL-адрес для следующего шага.

Затем вернитесь в терминал и выполните следующие действия, чтобы запустить клиент интерфейса командной строки (CLI) Smee:

Примечание. Следующие действия немного отличаются от инструкций "Использование CLI", которые вы увидите на странице канала Smee. Вам не нужно следовать инструкциям "Использовать клиент Node.js" или "Использование встроенной поддержки Probot".

  1. Установите клиент:

    $ npm install --global smee-client

  2. Запустите клиент (заменив https://smee.io/qrfeVRbFbffd6vD на значение для собственного домена):

    $ smee --url https://smee.io/qrfeVRbFbffd6vD --path /event_handler --port 3000

    Вы должны увидеть следующий результат:

    Forwarding https://smee.io/qrfeVRbFbffd6vD to http://127.0.0.1:3000/event_handler
Connected https://smee.io/qrfeVRbFbffd6vD

Команда smee --url <unique_channel> указывает Smee перенаправить все события веб-перехватчика (полученные каналом Smee) клиенту Smee, работающему на компьютере. Параметр --path /event_handler перенаправит события по маршруту /event_handler, который мы рассмотрим в одном из следующих разделов. Параметр --port 3000 указывает порт 3000, по которому сервер будет ожидать передачи данных. Используя Smee, компьютер не будет открыт для свободного доступа из Интернета, чтобы получить веб-перехватчики из GitHub. Вы также можете открыть этот веб-адрес Smee в браузере, чтобы проверить полезные данные веб-перехватчика по мере их поступления.

Рекомендуем оставить открытым это окно терминала и сохранить подключение Smee во время выполнения остальных действий, описанных в этом руководстве. Хотя можно отключить и повторно подключить клиент Smee, не теряя уникальный домен (в отличие от ngrok), но проще оставить его подключенным и выполнить другие задачи командной строки в другом окне терминала.

Шаг 2. Регистрация нового приложения в GitHub Apps

Если у вас еще нет учетной записи GitHub, пришло время создать ее. Не забудьте проверить электронную почту, прежде чем продолжить! Чтобы зарегистрировать новое приложение, перейдите на страницу параметров приложения в профиле GitHub и нажмите кнопку New GitHub App (Новое приложение GitHub).

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

Примечание. Вы всегда можете обновить эти параметры позже, чтобы указать на размещенный сервер.

  • Для поля Homepage URL (URL-адрес домашней страницы) используйте домен, выданный Smee.

  • Для поля Webhook URL (URL-адрес веб-перехватчика) снова используйте домен, выданный Smee.

  • Для поля Webhook secret (Секрет веб-перехватчика) создайте пароль для защиты конечных точек веб-перехватчика. Его должны знать только вы (и GitHub через эту форму). Секрет важен, так как вы будете получать полезные данные из общедоступного Интернета, поэтому будете использовать этот секрет для проверки отправителя веб-перехватчика. Обратите внимание, что в параметрах приложения GitHub секрет веб-перехватчика является необязательным, что для большинства случаев правильно, но для работы кода приложения-шаблона необходимо задать секрет веб-перехватчика.

  • На странице разрешений и веб-перехватчиков можно указать набор разрешений для приложения. Этот набор определяет объем данных, к которым у приложения есть доступ. В разделе Repository permissions (Разрешения репозитория) прокрутите вниз до Metadata (Метаданные) и выберите Access: Read-only. Если вы решите расширить это приложение-шаблон, то эти разрешения можно обновить позже.

  • В нижней части страницы Разрешения & веб-перехватчиков в разделе "Где можно установить GitHub App?" укажите, является ли это частным или общедоступным приложением.

    Это относится к тому, кто может его установить: только вы или все. Сейчас оставьте приложение частным, выбрав Only on this account (Только в этой учетной записи).

Нажмите кнопку Create GitHub App (Создать приложение GitHub), чтобы создать приложение!

Шаг 3. Сохранение закрытого ключа и идентификатора приложения

После создания приложения вы вернетесь на страницу параметров приложения. Здесь необходимо выполнить еще два действия:

  • Обратите внимание на идентификатор приложения, назначенный GitHub приложению, который отображается в разделе "О программе". Он потребуется для подготовки среды выполнения.

  • Создайте закрытый ключ для приложения. Он понадобиться позже для проверки подлинности приложения. Прокрутите вниз до раздела "Закрытые ключи" и щелкните Создать закрытый ключ. Сохраните полученный файл PEM (под названием app-name - date -private-key.pem) в каталоге, где вы его сможете найти еще раз.

Шаг 4. Подготовка среды выполнения

Чтобы обеспечить безопасность информации, рекомендуем поместить все секреты, связанные с приложением, в память компьютера, где приложение сможет их найти, а не помещать их непосредственно в код. Удобное средство разработки под названием dotenv загружает переменные среды для конкретного проекта из файла .env в ENV. Никогда не помещайте файл .env в GitHub. Это локальный файл, в котором хранятся конфиденциальные данные, которые не предназначены для общедоступного Интернета. Файл .env уже включен в файл репозитория .gitignore, чтобы предотвратить это.

Код шаблона, скачанный в разделе предварительных требований, уже содержит пример файла под названием .env-example. Переименуйте пример файла с .env-example на .env или создайте копию файла .env-example под названием .env. Вы еще не установили dotenv, но установите его позже с помощью этого краткого руководства при выполнении bundle install. Примечание. В кратких руководствах, ссылающихся на действия, описанные в этом руководстве, могут содержаться дополнительные переменные среды в файле .env-example. См. краткое руководство для проекта, клонированного на GitHub, чтобы настроить эти дополнительные переменные среды.

Эти переменные необходимо добавить в файл .env:

  • GITHUB_PRIVATE_KEY . Добавьте созданный и сохраненный ранее закрытый ключ. Откройте файл .pem в текстовом редакторе или используйте командную строку для отображения содержимого файла: cat path/to/your/private-key.pem. Скопируйте все содержимое файла в качестве значения GITHUB_PRIVATE_KEY в файл .env. Примечание. Так как PEM-файл содержит несколько строк, необходимо добавить кавычки вокруг значения, как в примере ниже.
  • GITHUB_APP_IDENTIFIER . Используйте идентификатор приложения, указанный в предыдущем разделе.
  • GITHUB_WEBHOOK_SECRET . Добавьте секрет веб-перехватчика.

Ниже приведен пример файла .env:

GITHUB_PRIVATE_KEY="-----BEGIN RSA PRIVATE KEY-----
...
HkVN9...
...
-----END DSA PRIVATE KEY-----"
GITHUB_APP_IDENTIFIER=12345
GITHUB_WEBHOOK_SECRET=your webhook secret

Шаг 5. Проверка кода шаблона приложения GitHub

Код приложения-шаблона уже содержит часть кода, который потребуется каждому приложению GitHub. В этом разделе описывается код, который уже есть в шаблоне приложения GitHub. При работе с этим разделом не нужно выполнять никаких действий. Если вы уже знакомы с кодом шаблона, можно перейти к разделу Шаг 6. Запуск сервера.

Откройте файл template_server.rb в предпочитаемом текстовом редакторе. В этом файле вы увидите комментарии, которые предоставляют дополнительный контекст для кода шаблона. Рекомендуем внимательно прочитать эти комментарии и даже добавлять собственные для сопровождения нового кода, который вы пишете.

В верхней части файла вы увидите set :port 3000, что задает порт, используемый при запуске веб-сервера в соответствии с портом, на который вы перенаправили полезные данные веб-перехватчика согласно инструкциям раздела Шаг 1. Запуск нового канала Smee.

В следующем коде, который вы увидите, будет объявление class GHApp < Sinatra::Application. Вы будете писать весь код для приложения GitHub в этом классе.

По умолчанию класс в шаблоне выполняет следующие действия:

Чтение переменных среды

Первое, что делает этот класс, — считывает три переменные среды, заданные в разделе Шаг 4. Подготовка среды выполнения, и сохраняет их в переменных для последующего использования:

# Expects that the private key in PEM format. Converts the newlines
PRIVATE_KEY = OpenSSL::PKey::RSA.new(ENV['GITHUB_PRIVATE_KEY'].gsub('\n', "\n"))

# Your registered app must have a secret set. The secret is used to verify
# that webhooks are sent by GitHub.
WEBHOOK_SECRET = ENV['GITHUB_WEBHOOK_SECRET']

# The GitHub App's identifier (type integer) set when registering an app.
APP_IDENTIFIER = ENV['GITHUB_APP_IDENTIFIER']

Включите ведение журнала.

Далее приведен блок кода, который включает ведение журнала во время разработки, что является средой по умолчанию в Sinatra. Этот код включает ведение журнала на уровне DEBUG, чтобы отобразить полезные выходные данные в терминале во время разработки приложения:

# Turn on Sinatra's verbose logging during development
configure :development do
  set :logging, Logger::DEBUG
end

Определение перед фильтром

Sinatra используется перед фильтрами, что позволяет выполнять код перед обработчиком маршрутов. Блок before в шаблоне вызывает четыре вспомогательных метода. Приложение-шаблон определяет эти вспомогательные методы в одном из следующих разделов.

# Before each request to the `/event_handler` route
before '/event_handler' do
  get_payload_request(request)
  verify_webhook_signature
  authenticate_app
  # Authenticate the app installation in order to run API operations
  authenticate_installation(@payload)
end

Определение обработчика маршрутов

Пустой маршрут включается в код шаблона. Этот код обрабатывает все запросы POST к маршруту /event_handler. Вы не будете писать этот обработчик событий в рамках данного краткого руководства, но ознакомитесь с другими краткими руководствами в качестве примера расширения этого приложения-шаблона.

post '/event_handler' do

end

Определение вспомогательных методов

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

Обработка полезных данных веб-перехватчика

Первый метод get_payload_request захватывает полезные данные веб-перехватчика и преобразует их в формат JSON, что значительно упрощает к ним доступ.

Проверка сигнатуры веб-перехватчика

Второй метод verify_webhook_signature выполняет проверку сигнатуры веб-перехватчика, чтобы убедиться, что событие создано GitHub. Дополнительные сведения о коде во вспомогательном verify_webhook_signature методе см. в разделе Защита веб-перехватчиков. Если веб-перехватчики защищены, этот метод записывает все входящие полезные данные в терминал. Код средства ведения журнала полезен при проверке работы веб-сервера, но его всегда можно удалить позже.

Проверка подлинности в качестве приложения GitHub

Для выполнения вызовов API вы будете использовать библиотеку Octokit. Для выполнения каких-либо интересных действий с помощью этой библиотеки от вас или, скорее, от вашего приложения потребуется проверка подлинности. Приложения GitHub имеют два метода проверки подлинности:

  • Проверка подлинности в качестве приложения GitHub с помощью JSON Web Token (JWT).
  • Проверка подлинности в качестве конкретной установки приложения GitHub с помощью маркера доступа установки.

Вы узнаете о проверке подлинности как установке в следующем разделе.

Сведения о проверке подлинности с помощью приложения GitHub позволяет выполнить несколько действий:

  • Вы можете получить общие сведения управления для приложения GitHub.
  • Вы можете запросить маркеры доступа для установки приложения.

Например, для получения списка учетных записей (организации и личных) с вашим установленным приложением можно выполнить проверку подлинности в качестве приложения GitHub. Но этот способ проверки подлинности не широкого спектра действий с API. Чтобы получить доступ к данным репозитория и выполнять операции от имени установки, необходимо пройти проверку подлинности в качестве установки. Для этого сначала необходимо пройти проверку подлинности в качестве приложения GitHub, чтобы запросить маркер доступа установки.

Прежде чем использовать библиотеку Octokit.rb для выполнения вызовов API, необходимо инициализировать клиент Octokit, прошедший проверку подлинности как приложение GitHub. Вспомогательный метод authenticate_app делает именно это!

# Instantiate an Octokit client authenticated as a GitHub App.
# GitHub App authentication requires that you construct a
# JWT (https://jwt.io/introduction/) signed with the app's private key,
# so GitHub can be sure that it came from the app an not altered by
# a malicious third party.
def authenticate_app
  payload = {
      # The time that this JWT was issued, _i.e._ now.
      iat: Time.now.to_i,

      # JWT expiration time (10 minute maximum)
      exp: Time.now.to_i + (10 * 60),

      # Your GitHub App's identifier number
      iss: APP_IDENTIFIER
  }

  # Cryptographically sign the JWT
  jwt = JWT.encode(payload, PRIVATE_KEY, 'RS256')

  # Create the Octokit client, using the JWT as the auth token.
  @app_client ||= Octokit::Client.new(bearer_token: jwt)
end

Приведенный выше код создает JSON Web Token (JWT) и использует его (вместе с закрытым ключом приложения) для инициализации клиента Octokit. GitHub проверяет проверку подлинности запроса, проверяя маркер с сохраненным открытым ключом приложения. Дополнительные сведения о работе этого кода см. в разделе Создание веб-токена JSON (JWT) для приложения GitHub.

Проверка подлинности от имени установки

Под установкой понимается учетная запись любого пользователя или организации, которые установили приложение. Даже если кто-то устанавливает приложение в нескольких репозиториях, то это считается одной установкой, так это происходит в рамках одной учетной записи. Последний вспомогательный метод authenticate_installation инициализирует клиент Octokit, прошедший проверку подлинности в качестве установки. Этот клиент Octokit используется для выполнения вызовов API, прошедших проверку подлинности.

# Instantiate an Octokit client authenticated as an installation of a
# GitHub App to run API operations.
def authenticate_installation(payload)
  installation_id = payload['installation']['id']
  installation_token = @app_client.create_app_installation_access_token(installation_id)[:token]
  @installation_client = Octokit::Client.new(bearer_token: installation_token)
end

Метод Octokit create_app_installation_access_token создает маркер установки. Этот метод принимает два аргумента:

  • Установка (целое число): идентификатор установки приложения GitHub.
  • Параметры (хэш, по умолчанию {}): настраиваемый набор параметров.

Каждый раз, когда приложение GitHub получает веб-перехватчик, он включает объект installation с id. Используя клиент, прошедший проверку подлинности в качестве приложения GitHub, вы передаете этот идентификатор методу create_app_installation_access_token для создания маркера доступа для каждой установки. Так как вы не передаете параметры в метод, то параметры по умолчанию имеют пустой хэш. Ответ для create_app_installation_access_token включает два поля: token и expired_at. Код шаблона выбирает маркер в ответе и инициализирует клиент установки.

При использовании этого метода каждый раз, когда приложение получает новые полезные данные веб-перехватчика, он создает клиент для установки, которая активировала событие. Этот процесс проверки подлинности позволяет приложению GitHub работать для всех установок в любой учетной записи.

Теперь все готово для выполнения вызовов API!

Шаг 6. Запуск сервера

Приложение пока ничего не делает, но на этом этапе его можно запустить на сервере.

Не закрывайте Smee на текущей вкладке в терминале. Откройте новую вкладку и с помощью cd перейдите в каталог, где вы клонировали код приложения-шаблона. Код Ruby в этом репозитории запустит веб-сервер Sinatra. Этот код имеет несколько зависимостей. Их можно установить, выполнив:

$ gem install bundler

А затем:

$ bundle install

После установки зависимостей можно запустить сервер:

$ bundle exec ruby template_server.rb

Вы должны получить примерно следующий ответ:

> == Sinatra (v2.0.3) has taken the stage on 3000 for development with backup from Puma
> Puma starting in single mode...
> * Version 3.11.2 (ruby 2.4.0-p0), codename: Love Song
> * Min threads: 0, max threads: 16
> * Environment: development
> * Listening on tcp://localhost:3000
> Use Ctrl-C to stop

Если появится сообщение об ошибке, убедитесь, что вы создали файл .env в каталоге с template_server.rb.

После запуска сервера его можно проверить, перейдя по адресу http://localhost:3000 в браузере. Если приложение работает должным образом, вы увидите полезную страницу с сообщением об ошибке "Sinatra не знает, что это не так".

Это хорошо! Несмотря на то, что это страница ошибки, такая страница Sinatra означает, что ваше приложение подключено к серверу должным образом. Вы видите это сообщение, так как вы ничего не предоставили приложению для отображения.

Шаг 7. Установка приложения в учетной записи

Вы можете проверить, ожидает ли сервер передачи данных приложения, активируя событие для получения. Простое событие, которое можно проверить, — это установка приложения в учетной записи GitHub, которая должна отправлять событие installation. Если приложение получит его, вы увидите некоторые выходные данные на вкладке терминала, на которой вы запустили template_server.rb.

Чтобы установить приложение, перейдите на страницу параметров приложения, выберите приложение и на боковой панели щелкните Install App (Установить приложение). Рядом с именем пользователя щелкните Install (Установить).

Вам будет предложено установить приложение во всех или выбранных репозиториях. Если вы не хотите устанавливать приложение во всех репозиториях, это нормально! Вы можете создать репозиторий-песочницу для тестирования и установить приложение там.

После нажатия кнопки Install (Установить) просмотрите выходные данные в терминале. Отобразятся примерно следующие сведения:

> D, [2018-06-29T15:45:43.773077 #30488] DEBUG -- : ---- received event integration_installation
> D, [2018-06-29T15:45:43.773141 #30488] DEBUG -- : ----         action created
> 192.30.252.44 - - [29/Jun/2018:15:45:43 -0400] "POST / HTTP/2" 200 2 0.0067
> D, [2018-06-29T15:45:43.833016 #30488] DEBUG -- : ---- received event installation
> D, [2018-06-29T15:45:43.833062 #30488] DEBUG -- : ----         action created
> 192.30.252.39 - - [29/Jun/2018:15:45:43 -0400] "POST / HTTP/2" 200 2 0.0019

Это хорошая новость! Это означает, что приложение получило уведомление об установке в учетной записи GitHub. Если вы видите примерно такое, приложение выполняется на сервере должным образом. 🙌

Если выходные данные не отображаются, убедитесь, что Smee работает правильно на другой вкладке терминала. Если нужно перезапустить Smee, обратите внимание, что также потребуется удалить и переустановить приложение, чтобы отправить событие installation в приложение еще раз и увидеть выходные данные в терминале. Если проблема не в Smee, см. другие причины в разделе Устранение неполадок.

Если вы хотите узнать, откуда поступают указанные выше выходные данные терминала, то это прописано в коде шаблона приложения в template_server.rb.

Устранение неполадок

Ниже указаны некоторые распространенные проблемы и предлагаемые решения. Если у вас возникнут другие проблемы, вы можете обратиться за помощью или советом в Обсуждения API и интеграции в сообществе GitHub.

  • Вопрос. При попытке установить клиент командной строки Smee возникает следующее сообщение об ошибке:

    > npm: command not found

    Ответ. Похоже, у вас не установлен диспетчер npm. Лучший способ установить его — скачать пакет Node.js по адресу https://nodejs.org и следовать инструкциям по установке для системы. Диспетчер npm будет установлен вместе с Node.js.

  • Вопрос. При запуске сервера возникает следующее сообщение об ошибке:

    > server.rb:38:in `initialize': Neither PUB key nor PRIV key: header too long (OpenSSL::PKey::RSAError)

    Ответ. Возможно, вы не настроили правильно переменную среды закрытого ключа. Переменная GITHUB_PRIVATE_KEY должна выглядеть следующим образом:

    GITHUB_PRIVATE_KEY="-----BEGIN RSA PRIVATE KEY-----
...
HkVN9...
...
-----END RSA PRIVATE KEY-----"

    Повторно убедитесь, что вы скопировали правильный открытый ключ в файл .env.

  • Вопрос. При запуске сервера происходит сбой со следующим сообщением об ошибке:

    > Octokit::Unauthorized ... 401 - Bad credentials`

    Ответ. Возможно, вы проходите проверку подлинности в качестве приложения GitHub, но не в качестве установки. Убедитесь, что вы следуете всем инструкциям из раздела Проверка подлинности в качестве установки и используете переменную экземпляра @installation_client (с проверкой подлинности с помощью маркера доступа к установке) для операций API, а не переменную экземпляра @app_client (с проверкой подлинности с помощью JWT). Переменная экземпляра @app_client может извлекать только общие сведения о приложении и получать маркеры доступа установки. Больше эта переменная ничего не может сделать в API.

  • Вопрос. Что делать, если мой сервер не ожидает передачи данных событий? Клиент Smee работает в окне терминала, и я устанавливаю приложение в репозитории на сайте GitHub, но не вижу выходных данных в окне терминала, где работает сервер.

    Ответ. Возможно, у вас не работает клиент Smee, так как вы выполняете команду Smee с неправильными параметрами или в параметрах приложения GitHub указан неправильный домен Smee. Сначала проверьте, работает ли клиент Smee на вкладке терминала. Если проблема не в этом, посетите страницу параметров приложения и проверьте поля, показанные в разделе Шаг 2. Регистрация нового приложения в GitHub Apps. Убедитесь, что домен в этих полях соответствует домену, который вы использовали в команде smee -u <unique_channel> при работе с разделом Шаг 1. Запуске нового канала Smee. Если ничего из указанного выше не помогло, убедитесь, что выполняется полная команда Smee, включая параметры --path и --port, например: smee --url https://smee.io/qrfeVRbFbffd6vD --path /event_handler --port 3000 (заменив https://smee.io/qrfeVRbFbffd6vD на значение для собственного домена Smee).

  • Вопрос. В выходных данных отладки я получаю ошибку 404 Octokit::NotFound:

    2018-12-06 15:00:56 - Octokit::NotFound - POST http(s)://HOSTNAME/api/v3/app/installations/500991/access_tokens: 404 - Not Found // See: /v3/apps/#create-a-new-installation-token:

    Ответ. Убедитесь, что переменные в файле .env правильные. Убедитесь, что в других файлах переменных среды (например, bash_profile) не заданы идентичные переменные. Вы можете проверить переменные среды, которые использует приложение, добавив инструкции puts в код приложения и повторно выполнив его. Например, чтобы убедиться в правильности набора закрытых ключей, можно добавить puts PRIVATE_KEY в код приложения:

    PRIVATE_KEY = OpenSSL::PKey::RSA.new(ENV['GITHUB_PRIVATE_KEY'].gsub('\n', "\n"))
puts PRIVATE_KEY

Заключение

После прохождения этого руководства вы узнали об основных стандартных блоках для разработки приложений GitHub! Для этого вы:

  • Зарегистрировали новое приложение GitHub.
  • Использовали Smee для получения полезных данных веб-перехватчика.
  • Запустили простой веб-сервер с помощью Sinatra.
  • Выполнили проверку подлинности в качестве приложения GitHub.
  • Выполнили проверку подлинности в качестве установки.

Дальнейшие действия

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