Advanced CLI Usage
This page details some of the more advanced options of the FireFly CLI
Understanding how the CLI uses FireFly releases¶
The manifest.json
file¶
FireFly has a manifest.json
file in the root of the repo. This file contains a list of versions (both tag and sha) for each of the microservices that should be used with this specific commit.
Here is an example of what the manifest.json
looks like:
{
"ethconnect": {
"image": "ghcr.io/hyperledger/firefly-ethconnect",
"tag": "v3.0.4",
"sha": "0b7ce0fb175b5910f401ff576ced809fe6f0b83894277c1cc86a73a2d61c6f41"
},
"fabconnect": {
"image": "ghcr.io/hyperledger/firefly-fabconnect",
"tag": "v0.9.0",
"sha": "a79a4c66b0a2551d5122d019c15c6426e8cdadd6566ce3cbcb36e008fb7861ca"
},
"dataexchange-https": {
"image": "ghcr.io/hyperledger/firefly-dataexchange-https",
"tag": "v0.9.0",
"sha": "0de5b1db891a02871505ba5e0507821416d9fa93c96ccb4b1ba2fac45eb37214"
},
"tokens-erc1155": {
"image": "ghcr.io/hyperledger/firefly-tokens-erc1155",
"tag": "v0.9.0-20211019-01",
"sha": "aabc6c483db408896838329dab5f4b9e3c16d1e9fa9fffdb7e1ff05b7b2bbdd4"
}
}
Default CLI behavior for releases¶
When creating a new stack, the CLI will by default, check the latest non-pre-release version of FireFly and look at its manifest.json
file that was part of that commit. It will then use the Docker images referenced in that file to determine which images it should pull for the new stack. The specific image tag and sha is written to the docker-compose.yml
file for that stack, so restarting or resetting a stack will never pull a newer image.
Running a specific release of FireFly¶
If you need to run some other version that is not the latest release of FireFly, you can tell the FireFly CLI which release to use by using the --release
or -r
flag. For example, to explicitly use v0.9.0
run this command to initialize the stack:
Running an unreleased version of one or more services¶
If you need to run an unreleased version of FireFly or one of its microservices, you can point the CLI to a specific manifest.json
on your local disk. To do this, use the --manifest
or -m
flag. For example, if you have a file at ~/firefly/manifest.json
:
If you need to test a locally built docker image of a specific service, you'll want to edit the manifest.json
before running ff init
. Let's look at an example where we want to run a locally built version of fabconnect. The same steps apply to any of FireFly's microservices.
Build a new image of fabconnect locally¶
From the fabconnect project directory, build and tag a new Docker image:
Edit your manifest.json
file¶
Next, edit the fabconnect
section of the manifest.json
file. You'll want to remove the tag
and sha
and a "local": true
field, so it looks like this:
Initialize the stack with the custom manifest.json
file¶
If you are iterating on changes locally, you can get the CLI to use an updated image by doing the following:
- Whenever the CLI does its first time setup, it will use your newly built local docker image
- If you've already run the stack, you can run
ff reset <stack_name>
andff start <stack_name>
to reset the data, and use the newer image
Running a locally built FireFly Core image¶
You may have noticed that FireFly core is actually not listed in the manifest.json file
. If you want to run a locally built image of FireFly Core, you can follow the same steps above, but instead of editing an existing section in the file, we'll add a new one for FireFly.
Build a new image of FireFly locally¶
From the firefly project directory, build and tag a new Docker image: