Слияние кода завершено, страница обновится автоматически
Это место для начала, если вы хотите запустить Cactus на вашей локальной машине или если вы планируете внести свой вклад.
Это руководство предназначено не для использования Cactus в ваших проектах с бизнес-логикой, а для людей, желающих сделать изменения в коде Cactus. Если вы просто планируете использовать Cactus как npm зависимости для вашего проекта, то вам может вообще не потребоваться это руководство.
Проект использует TypeScript для backend и frontend компонентов.
Мы приложили много усилий, чтобы обеспечить быстрые итерации разработки (если вы считаете иначе, пожалуйста, сообщите об ошибке). При работе внутри фреймворка.Если вы замечаете, что слишком долго ждете завершения сборки, большую часть времени это можно исправить с помощью скрипта npm run watch, который автоматически пересобирает пакеты при их модификации (только те пакеты, которые были изменены, а не все сразу).Он также поддерживает повторное выполнение генератора OpenAPI при обновлении любых файлов спецификаций openapi.json, которые мы используем для описания наших конечных точек.
Скрипт npm run watch в действии:
Используйте заранее настроенную среду:
Или установите зависимости уровня ОС вручную:
nvm install 18.19.0
nvm use 18.19.0
npm run enable-corepack (внутри проектной директории)Мы рекомендуем использовать WSL2 или любую виртуальную машину с Linux (или реальный сервер). Мы наиболее часто тестируем на Ubuntu 20.04 LTS.
git clone https://github.com/hyperledger/cactus.git
Специфика для Windows: ошибка "слишком длинный путь к файлу" при клонировании. Для исправления откройте PowerShell с правами администратора и выполните следующее:
git config --system core.longpaths true
cd cactus
npm run enable-corepack
yarn run configure
На этом этапе все пакеты должны быть собраны для разработки.
Вы можете приступить к внесению своих изменений (используйте свой собственный форк и ветку с новыми функциями) или просто запустить существующие тесты и отладить их, чтобы понять, как они работают вместе.
Например, вы можете запустить тест конечной точки состояния через REST API с помощью этой команды:
npx tap --ts --timeout=600 packages/cactus-test-plugin-htlc-eth-besu/src/test/typescript/integration/plugin-htlc-eth-besu/get-single-status-endpoint.test.ts
```*Вы также можете запустить сервер API* и проверить более сложные сценарии с произвольным списком плагинов, загруженных в Cactus. Это полезно, если вы намерены разрабатывать свой плагин либо как плагин, поддерживаемый Cactus, либо самостоятельно.
```sh
npm run generate-api-server-config
Обратите внимание, что эта задача создаёт файл .config.json в корне проекта с примером конфигурации, который можно использовать как хорошую отправную точку для вас, чтобы сделать изменения, необходимые вам.
Самым интересным аспектом файла .config.json является массив плагинов, который принимает список имен пакетов плагинов и их опций (что может быть любым объектом JSON).
Обратите внимание, что для включения плагина достаточно указать его имя пакета npm. Это важно, так как это позволяет вам иметь свои собственные плагины в соответствующих, независимых репозиториях GitHub и пакетах npm, где вам не требуется получать явного одобрения от поддерживателей Cactus для создания/поддержки вашего плагина. При удовлетворении содержанием файла .config.json вы можете выполнить следующее:
npm run start:api-server
```После запуска сервера API в логах будет указано, что плагины были загружены,
и что API доступен по порту, который вы указали (по умолчанию 4000). Веб-интерфейс (Cockpit) деактивирован по умолчанию,
но может быть активирован путём изменения значения свойства `cockpitEnabled` на `true`;
он становится доступен через порт, указанный в вашем конфигурационном файле (по умолчанию 3000).> Возможно, вам потребуется вручную активировать паттерны CORS в конфигурационном файле.
Это может быть немного неудобно, но это то, с чем мы не можем пойти на компромиссы, хотя очень ценим опыт разработчиков.
Мы решили, что программное обеспечение должно быть "безопасным по умолчанию" во главу угла, а возможность кастомизации/уменьшения безопасности должна предоставляться как опциональная функция, а не начинаться с этого состояния.
На данном этапе, при запущенном сервере API, вы можете:
* Тестировать REST API непосредственно с помощью таких инструментов, как cURL или Postman
* Разрабатывать свои собственные приложения против него с использованием `Cactus API Client(s)`
* Создавать и тестировать свои собственные плагины
## Дерево решений скриптов сборки
Скрипт `npm run watch` должен покрывать 99% случаев работы над кодом Cactus и его повторной компиляции, но для оставшихся 1% вам придется работать с другими скриптами сборки. Обычно это требуется только тогда, когда вы добавляете новые зависимости (npm пакеты) как часть чего-то, что вы реализуете.
В Cactus существует множество различных скриптов сборки для предоставления участникам более детального контроля над теми частями фреймворка, которые они хотят собирать.> Вопрос: Почему такая сложность множества скриптов сборки?
> Ответ: Мы могли бы просто использовать один скрипт сборки, который будет собирать всё всегда, но это было бы кошмаром ждать после того, как вы изменили всего одну строку кода, например.Чтобы понять, какой скрипт можно использовать для повторной сборки Cactus, пройдите по следующему дереву решений (и помните, что у нас есть `npm run watch`):
## Настройка SSH для использования upterm
Загрузите ваш открытый ключ на GitHub, если это ещё не сделано. Открытый ключ необходим для присоединения SSH-соединения для использования upterm. Для подробной инструкции см. [Создание нового SSH-ключа и его добавление в ssh-agent](https://docs.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent).
Найдите файл `ci.yml` в папке `.github/workflows` и добавьте следующий код в этот файл:
```yaml
- name: Настройка сессии upterm
uses: lhotari/action-upterm@v1
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
Помните, что SSH-сессия upterm должна располагаться после шага проверки исходного кода (uses: actions/checkout@v4.1.1), чтобы гарантировать, что процесс CI не будет зависеть до выполнения шага отладки. Изменение файла ci.yml создаст новый шаг сборки в .github/workflows, который запустит новую сессию upterm. Для получения более подробной информации см. Отладка действий GitHub с помощью SSH.
Создание pull request для изменённого файла ci.yml позволит запустить тесты CI. Есть два способа перехода к CI.
checks.Actions внутри основного репозитория Hyperledger Cactus.Щелкните по CI Cactus workflow. В списке должны быть указаны новые задачи, которые вы создали под задачами build (ubuntu-22.04). Щелкните по новой задаче (так называемому вашему шагу сборки) и найдите SSH-сеанс в выпадающем меню Session setup upterm. Скопируйте команду SSH, которая начинается со слова ssh и заканчивается .dev (например, ssh **********:***********@uptermd.upterm.dev). Откройте вашу операционную систему и вставьте скопированную команду SSH, чтобы начать сессию upterm.Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )