feat(cli): enhance --version outputs for merod cli

[dotandev]

Description

Attempts to resolve #1074.

This PR enhances the --version output of the merod CLI by embedding richer build-time metadata, including:

• Git commit hash
• Git describe (tag + distance + dirty state)
• Rust compiler version
• Protocol version (from crate's major version)

This improves traceability and simplifies debugging across environments with custom or unstable builds.

Test Plan

Output of ./target/debug/merod --version after build:

merod (release 0.6.0) (build 0.5.0-48-g9e3a7c9-dirty) (commit) (rustc 1.85.0) (protocol 0)

Documentation Update

N/A

[dotandev]

@antonpaisov ,

The commit hash returns nothing for now, but when I run :

git rev-parse --short HEAD  

it gives me the hash, but not with the cli, help me review if there is a reason for that.

[miraclx]

Hi @dotandev, thanks for taking this up.

Can you apply the format established in the previous attempt: #1212

this patch applies to both meroctl and merod, so so you should host all version specific structures in a new calimero-version crate (or a new module in calimero-primitives works too, maybe even preferable)

[dotandev]

@miraclx

I have this build error.

I have tried to upgrade the lib but it totally disrupted the build.

 stellar_baselib::operation::Operation::invoke_host_function(
   |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
93 |                     invoke_host_function_op.host_function,
   |                     ------------------------------------- argument #1 of type `&stellar_baselib::operation::Operation` is missing
94 |                     auth,
   |                     ---- unexpected argument #2 of type `std::option::Option<VecM<stellar_baselib::xdr::SorobanAuthorizationEntry, u32::MAX>>`
   |
note: method defined here

 pub fn invoke_host_function(
   |            ^^^^^^^^^^^^^^^^^^^^
help: did you mean
   |
92 |                 stellar_baselib::operation::Operation::invoke_host_function(/* &stellar_baselib::operation::Operation */, invoke_host_function_op.host_function, None)
   |                                                                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

For more information about this error, try `rustc --explain E0308`.
error: could not compile `soroban-client` (lib) due to 1 previous error

[antonpaisov]

@miraclx could you please have a look at this one? :)

[miraclx]

without looking too deeply, there's nothing immediately obvious to me

cc: @alenmestrov, maybe something is immediately obvious to you that won't be to me, but if this compiles on master, consider reverting your lockfile to the version on master, and rebuild

$ git checkout master Cargo.lock

[miraclx]

nearly there

[dotandev]

can you expataite on these?

#1257 (comment)

#1257 (comment)

and on this--
#1257 (comment)

I was asked to implement it as calimero_rustc_version

has that changed?

@miraclx

[miraclx]

I was asked to implement it as calimero_rustc_version

That's not what you were asked - #1257 (comment)

[miraclx]

there's one last item pending

#1257 (comment)

[dotandev]

I didn't add the version.worskpace because it failed locally, same on CI:

https://github.com/calimero-network/core/actions/runs/15534559089/job/43730538856?pr=1257

then, there's another fail in a previous CI from the SDK crate after I pulled from master:

https://github.com/calimero-network/core/actions/runs/15533622123/job/43727709956?pr=1257

@miraclx

[miraclx]

ah my bad we don't have a global version spec, we just manually unified them, you can revert to 0.1.0 in both crates then!

then, there's another fail in a previous CI from the SDK crate after I pulled from master:

that was due to your toolchain channel change to stable, which you've now reverted so I don't expect it to persist

[dotandev]

0.60 you mean?

@miraclx

[miraclx]

0.60 you mean?

merod & meroctl should be 0.1.0 so we don't have to manually keep versions in 3 places consistent

also, we need to update the version extraction for the release logic to pick from calimero-version crate instead of merod or meroctl:

core/.github/workflows/release.yml

Line 61 in 477610e

binary_version=$(cargo metadata --format-version 1 --no-deps | jq -r --arg binary "$binary" '.packages[] | select(.name == $binary) | .version')

[dotandev]

@miraclx

any thoughts on why the tests are failing?

[github-actions]

E2E tests report

Protocol: ethereum

Application/Step	0. app install (AllMembers)	1. ctx create	2. ctx invite-join	3. wait (Consensus)	4. call (create_new_proposal, Inviter)	5. get proposals	6. call (send_proposal_messages, Inviter)	7. wait (Broadcast)	8. call (get_proposal_messages, Invitees)	9. call (approve_proposal, Invitees)	10. verify external state
demo-blockchain-integrations	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅

Application/Step	0. app install (AllMembers)	1. ctx create	2. alias create	3. call (set, Inviter)	4. call (get, Inviter)	5. ctx invite-join	6. wait (Consensus)	7. call (get, AllMembers)	8. call (set, Inviter)	9. wait (Broadcast)	10. call (get, AllMembers)
kv-store-test	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅

Protocol: icp

Application/Step	0. app install (AllMembers)	1. ctx create	2. ctx invite-join	3. wait (Consensus)	4. call (create_new_proposal, Inviter)	5. get proposals	6. call (send_proposal_messages, Inviter)	7. wait (Broadcast)	8. call (get_proposal_messages, Invitees)	9. call (approve_proposal, Invitees)	10. verify external state
demo-blockchain-integrations	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅

Application/Step	0. app install (AllMembers)	1. ctx create	2. alias create	3. call (set, Inviter)	4. call (get, Inviter)	5. ctx invite-join	6. wait (Consensus)	7. call (get, AllMembers)	8. call (set, Inviter)	9. wait (Broadcast)	10. call (get, AllMembers)
kv-store-test	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅

Protocol: near

Application/Step	0. app install (AllMembers)	1. ctx create	2. ctx invite-join	3. wait (Consensus)	4. call (create_new_proposal, Inviter)	5. get proposals	6. call (send_proposal_messages, Inviter)	7. wait (Broadcast)	8. call (get_proposal_messages, Invitees)	9. call (approve_proposal, Invitees)	10. verify external state
demo-blockchain-integrations	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅

Application/Step	0. app install (AllMembers)	1. ctx create	2. alias create	3. call (set, Inviter)	4. call (get, Inviter)	5. ctx invite-join	6. wait (Consensus)	7. call (get, AllMembers)	8. call (set, Inviter)	9. wait (Broadcast)	10. call (get, AllMembers)
kv-store-test	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅

Protocol: stellar

Application/Step	0. app install (AllMembers)	1. ctx create	2. ctx invite-join	3. wait (Consensus)	4. call (create_new_proposal, Inviter)	5. get proposals	6. call (approve_proposal, Invitees)	7. verify external state	8. call (create_new_proposal, Inviter)	9. get proposals	10. call (send_proposal_messages, Inviter)	11. wait (Broadcast)	12. call (get_proposal_messages, Invitees)
demo-blockchain-integrations	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅

Application/Step	0. app install (AllMembers)	1. ctx create	2. alias create	3. call (set, Inviter)	4. call (get, Inviter)	5. ctx invite-join	6. wait (Consensus)	7. call (get, AllMembers)	8. call (set, Inviter)	9. wait (Broadcast)	10. call (get, AllMembers)
kv-store-test	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅