[FEATURE] - Node Release artifacts

[rdlrt]

What

1. Currently the CI build of cardano-node brings across quite a few binaries and configuration directory, many of these do not really need to be average user-facing (and in sync with cabal build). Also, one the important CLIs for working with key/addresses is not part of these cardano-addresses.

   -configuration/
   -trace-dispatcher-examples
   -stake-credential-history
   -scan-blocks-pipelined
   -scan-blocks
   -plutus-example
   -locli
   -ledger-state
   -db-synthesizer
   -db-converter
   -db-analyser
   -chain-sync-client-with-ledger-state
   -cardano-topology
   -cardano-testnet
   -cardano-node-chairman
   cardano-submit-api
   cardano-node
   cardano-cli
   bech32
   +cardano-ping
   +cardano-addresses

While I have no real inputs on the CI runs for each commit, it would be good to have the release binaries to be more user facing. This will also avoid third-party builder scripts to provide sudden support because the build feature was changed/updated (see section below).

2. Would be nice for the binaries to be made available against https://<static-URL>/<component>/<version> (including latest redirecting to latest release marked for mainnet use), that can be referred to across documentations without having to drill down into scanning links from release pages.

Why

With the recent move to CHaP, cardano-node 1.35.4 broke cabal install commands, along with result removing certain components from external repos (eg: cardano-addresses, cardano-ping now need additional deps in local to build, and install fails due to ouroboros-consensus-cardano-tools) - the issue was already fixed by reverting for master branch, and expect it'll already be taken care of via CHaP soon, but there is no guarantee for downstream build scripts that things will not change again, requiring action on their ends. Having pre-built binaries that are actually complete and not involve extracting more and removing unnecessary components to SPOs will help adopt automation slightly better downstream.

Personas

• [x] SPOs
• [x] dApp Devs
• [ ] Exchanges
• [ ] Wallets
• [x] 3rd party tools
• [ ] ADA holders

Definition of Done (DoD)

• [ ] Acceptance Criteria + User Stories & DoD created and singed-off (by PO, dev & test owners)
• [ ] Builds successfully on CI
• [ ] Code & Test review (as per Acceptance Criteria)
• [ ] There is documentation and/or examples for the new functionality (usage/response)
• [ ] Log/record changes on Vnext (or similar depending on what we adopt)
• [ ] Ticket number(s) included in PR description
• [ ] All Acceptance Criteria met and covered by dev/unit/property/integration tests
• [ ] System/E2E automated tests + System Test Engineer Owner Sign-off

NOTE: Ideally, we should merge only fully implemented and tested features into the master branch. So all the above steps are required for the PR to be merged.
In order to avoid the PRs becoming stale and requiring to be rebased on master, these can be merged after a reasonable time (current agreement is 3 days) if the System Test Engineer Owner's sign-off was not provided (last step in the DoD).

IMPORTANT: Any deviation from the plan should be discussed and agreed as a comment in the Feature file.

Sign-off

• [ ] Product Owner
• [ ] Dev Owner
• [ ] System Test Engineer Owner

Related PRs

-

Acceptance Criteria

[CarlosLopezDeLara]

cc @disassembler

[Quantumplation]

Chiming in as a dApp developer to say this would be useful for us as well :)

[disassembler]

cardano-addresses is not part of it because it's not a dependency (and we don't want to introduce it as one). The cardano-wallet releases I believe include cardano-addresses. As for trimming the binaries, I'm all for that. From my perspective, the ones used are:

• cardano-node
• cardano-cli
• bech32 (useful for decoding addresses)
• cardano-ping (soon to be embedded in cardano-cli in a future release)
• db-synthesizer (allows creating empty blocks for local chains with a set of pool keys)

I'd like to get input from devs/community before removing things from the release tarball.

With the shutdown of hydra, we moved the binaries to a more sane path: https://update-cardano-mainnet.iohk.io/cardano-node-releases/cardano-node-1.35.4-linux.tar.gz

Another option would be to not have a tarball at all and just extract the files directly into something like https://update-cardano-mainnet.iohk.io/cardano-node-releases//<version>/<arch>/<binary>. I'm open to suggestions from developers/users on what their preference would be.

[Quantumplation]

@disassembler having dedicated download links for each binary, plus a somewhat opinionated "bundle" of binaries would be ideal; and +1 for having /latest as an option in place of version, for spinning up developer environments dynamically.

[rdlrt]

I'd like to get input from devs/community before removing things from the release tarball. ... cardano-node cardano-cli bech32 (useful for decoding addresses) cardano-ping (soon to be embedded in cardano-cli in a future release)

You might need to add cardano-submit-api as it's an artifact from node repo (as well as used by folks, tho there are arguably better options around). But other than that I have not yet seen any other binaries referenced in any open source scripts or mentioned in SPO workgroup or testnet channel. Having these 5 - by itself - will reduce size of archives already, but up to your preference on whether you want to make them available individually (in case of which - you can upload artifacts independently.

But ye - having /latest is really desirable across documentation sites as well as for provisioning scripts. An addition/alternative to /latest could be /current which is recommended to be used for mainnet

[TrevorBenson]

I agree with the comments about /latest and/or /current. However I would also like to have versioned links, especially for config and topology files. Otherwise this can lead to problems when a breaking change occurs.

For example the P2P topology change for 1.35.6 causes downloading the current link for preview topology and running with 1.35.5 to lead to startup failures, specifically error: cardano-node: FatalError {fatalErrorMessage = "Cardano.Node.Run.handleSimpleNodeP2P.readTopologyFile: Is your topology file formatted correctly? Expecting P2P Topology file format. The port and valency fields should be numerical. If you specified the correct topology file make sure that you correctly setup EnableP2P configuration flag. Error in $: key \"LocalRoots\" not found"}

[rdlrt]

However I would also like to have versioned links

Yes, that is what the issue description (point 2) says 🙂 (<component>/<version> - and in addition, <component>/latest / <component>/<current> )

[TrevorBenson]

Yes, that is what the issue description (point 2) says (<component>/<version> - and in addition, <component>/latest / <component>/<current> )

Yep, just making sure to voice an opinion for both options so Sam knows you are not the only dev requesting a versioned resource as he obtains additional input.

[reqlez]

cardano-addresses is not part of it because it's not a dependency (and we don't want to introduce it as one). The cardano-wallet releases I believe include cardano-addresses. As for trimming the binaries, I'm all for that. From my perspective, the ones used are:

* cardano-node

* cardano-cli

* bech32 (useful for decoding addresses)

* cardano-ping (soon to be embedded in cardano-cli in a future release)

* db-synthesizer (allows creating empty blocks for local chains with a set of pool keys)

I'd like to get input from devs/community before removing things from the release tarball.

With the shutdown of hydra, we moved the binaries to a more sane path: https://update-cardano-mainnet.iohk.io/cardano-node-releases/cardano-node-1.35.4-linux.tar.gz

Another option would be to not have a tarball at all and just extract the files directly into something like https://update-cardano-mainnet.iohk.io/cardano-node-releases//<version>/<arch>/<binary>. I'm open to suggestions from developers/users on what their preference would be.

What about the tracer? A bunch of work went into it recently, could be useful for people who rather not setup external monitoring tools, or use 3rd party scripts?

[rdlrt]

@disassembler - bumping this , as it hasnt changed a lot (especially wrt /latest or /current that node team recommends for use on mainnet), which can then be referenced in documentation and automation scripts downstream