Выпуск

Hyperledger Fabric использует Github Actions Release workflow.

При создании нового релиза публикуются следующие артефакты:

• Github release с примечаниями к выпуску и прикреплёнными двоичными файлами для следующих архитектур:

  • darwin-amd64;
  • darwin-arm64 (новый начиная с версии v2.5.0);
  • linux-amd64;
  • linux-arm64 (новый начиная с версии v2.5.0);
  • windows-amd64.

• Образы DockerHub для peer, orderer, ccenv, baseos, tools (CLI) для следующих архитектур:

  • linux-amd64;
  • linux-arm64 (новый начиная с версии v2.5.0).

Перед выпуском

Проверьте работоспособность CI fabric-test (https://dev.azure.com/Hyperledger/Fabric-Test/_build) и fabric-samples (https://github.com/hyperledger/fabric-samples/actions). fabric-samples можно обновить, чтобы использовать локально созданные образы fabric. В качестве альтернативы CI fabric-samples может быть обновлён для использования официального предварительного выпуска fabric на Github (например, alpha, beta, rc).

Релиз обычно вырезается из стабильной ветки релиза, например, release-2.5, но может быть вырезан из ветки main (предварительные, альфа- и бета-релизы часто вырезаются из ветки main, прежде чем релиз стабилизируется в собственной ветке релиза).

Создайте коммит релиза, который обновляет версию, документацию, примечания к релизу, скрипты установки. Пример pull request.

Создать релиз

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

• Укажите имя тега и соответствующее название релиза, например v2.5.0.
• Выберите ветку для релиза.

Технически это просто создаст релиз с тегом без артефактов, а затем действие пометки фактически запустит рабочий процесс выпуска, который публикует артефакты релиза.

Рабочий процесс выпуска выполняет 3 задания:

• Сборка бинарных файлов Fabric;
• Сборка и отправка образов Docker;
• Создание релиза Github на основе release_notes/vX.X.X.md и собранных в первом задании бинарных файлов.

Перейдите к рабочему процессу выпуска для отслеживания прогресса.

[ПРИМЕЧАНИЕ ДЛЯ версии release-2.2] — версия release-2.2 всё ещё использует вручную запущенный рабочий процесс вместо описанного выше триггера тегов. Вместо этого выполните следующие действия:

• Перейдите к Release workflow;
• Выберите запуск рабочего процесса для ветки release-2.2;
• Установите версию, двухзначную версию и хэш коммита, нажмите «Запустить рабочий процесс».

Протестировать артефакты выпуска

Убедитесь, что Github release и образы DockerHub созданы.

Загрузите артефакты и запустите тестовую сеть, как это сделал бы пользователь, читающий документацию:

curl -sSLO https://raw.githubusercontent.com/hyperledger/fabric/main/scripts/install-fabric.sh && chmod +x install-fabric.sh

./install-fabric.sh --fabric-version 2.5.0 --ca-version 1.5.6

cd fabric-samples/test-network
./network.sh up createChannel -ca -c mychannel -s couchdb
./network.sh deployCC -ccn basicgo -ccp ../asset-transfer-basic/chaincode-go/ -ccl go

export PATH=${PWD}/../bin:$PATH
export FABRIC_CFG_PATH=$PWD/../config/
export CORE_PEER_TLS_ENABLED=true
export CORE_PEER_LOCALMSPID=Org1MSP
export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt
export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
export CORE_PEER_ADDRESS=localhost:7051

peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -n basicgo --peerAddresses localhost:7051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses localhost:9051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt -c '{"function":"InitLedger","Args":[]}'

peer chaincode query -C mychannel -n basicgo -c '{"Args":["GetAllAssets"]}'

docker logs peer0.org1.example.com

./network.sh down

После релиза

В ветке релиза Fabric обновите версию до следующей ожидаемой версии (если она известна).

В основной ветке Fabric обновите документацию и скрипты, чтобы упомянуть новый релиз. Пример запрос на извлечение.

Обновите CI для fabric-samples, чтобы использовать новый релиз.

Основная ветка fabric-samples обычно настроена для работы с последними версиями из ветки релиза и основной ветки, поэтому обычно в fabric-samples теги не требуются. Однако для предыдущих веток fabric-samples, таких как release-2.2, требуется, чтобы в последнем коммите release-2.2 были теги для выпусков fabric v2.2.x, чтобы при клонировании образцов через скрипт установки проверялся соответствующий выпуск образцов. Пример процедуры пометки для администратора fabric-samples:

git tag v2.2.11 c3a0e81
git push origin v2.2.11