Skip to content

Latest commit

 

History

History
94 lines (63 loc) · 5.16 KB

RELEASING.md

File metadata and controls

94 lines (63 loc) · 5.16 KB
Raw

Releasing

Hyperledger Fabric uses a Github Actions Release workflow.

The following artifacts are published when creating a new release:

  • Github release with release notes and attached binary tars for the following architectures:

    • darwin-amd64
    • darwin-arm64 (new since v2.5.0)
    • linux-amd64
    • linux-arm64 (new since v2.5.0)
    • windows-amd64

  • DockerHub images for peer, orderer, ccenv, baseos, tools (CLI) for the following architectures:

    • linux-amd64
    • linux-arm64 (new since v2.5.0)

Before Releasing

Verify fabric-test and fabric-samples CI is healthy. fabric-samples can be updated to utilize locally built fabric images. Alternatively fabric-samples CI can be updated to utilize an official fabric Github pre-release (e.g. alpha, beta, rc).

Releases are typically cut from a stable release branch, e.g. release-2.5, but can be cut from main branch (preview, alpha, and beta releases are often cut from main branch before a release stabilizes in its own release branch).

Create a release commit that updates version, documentation, release notes, install scripts. Example pull request.

Create Release

Draft a GitHub release on the releases page to trigger the release workflow to publish the new release.

  • Specify a tag name and matching release title, e.g. v2.5.0.
  • Choose the branch to release from

Technically, this will simply create a tagged release with no artifacts, and then the tagging action will actually trigger the release workflow that publishes the release artifacts.

The release workflow performs 3 jobs:

  • Build Fabric Binaries
  • Build and Push docker images
  • Create Github Release based on release_notes/vX.X.X.md and binaries built in first job

Navigate to the release workflow to monitor progress.

[NOTE FOR release-2.2 ONLY] - release-2.2 still uses a manually dispatched workflow instead of the tag trigger described above. Follow these steps instead:

  • Navigate to Release workflow
  • Select to run workflow for branch release-2.2
  • Set the version, two digit version, and commit hash, click Run Workflow

Test release artifacts

Verify Github release and DockerHub images got created.

Pull down the artifacts and run test-network as a user reading the documentation would:

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/[email protected]/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

After releasing

In the fabric release branch, update the version to next expected version (if known).

In the fabric main branch, update the docs and scripts to mention the new release. Example pull request.

Update fabric-samples CI to utilize the new release.

fabric-samples main branch is typically set up to work with latest fabric release branch and main branch releases, therefore no tag is typically required in fabric-samples. However, prior fabric-samples release branches such as release-2.2 require the latest release-2.2 commit to have tags for the fabric v2.2.x releases, so that when users clone the samples via the install script the corresponding samples release will be checked out. Example tagging procedure for a fabric-samples administrator:

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