ci: improve deployment workflow

[Mirko-von-Leipzig]

The current deploy/release/packaging workflows have some short-comings.

They duplicate steps and also couple the release workflows with the deployment steps. This makes them difficult to adapt to requirement changes, especially by someone not familiar with the process that got us to this stage.

To make things easy to refactor and redesign I suggest we use actions insofar as possible. These are more flexible than workflow runs as they can use things from the current workflow.

github actions

We already have the ssm-command wrapped as an action. I suggest we similarly create an action to create a debian package, and an action to deploy to an instance.

This will give us greater flexibility in how we piece these together.

triggers

We should also reconsider our triggers; which will be easier to change once we have the pieces in place.

I suggest we move away from automatic triggers for deploys, at least for now. Part of the reason is that sometimes we may want to upgrade a node (e.g. now with 0.5.0 -> 0.5.1) instead of replacing the chain.

I'm thinking a manual workflow_dispatch with options:

network: devnet | testnet
reset: true | false                  # reset network
ref-type: version | branch | commit  # what to deploy
ref: string                          # which version/branch/commit to use

versioning

We should also improve the version reported by our binaries. Currently miden-node --version will just report back the Cargo.toml version which is fine for formal releases, but rather useless for anything else.

I suggest we simply use git describe --tags which prints:

<previous-tag>-<commits-since-tag>-<SHA>

though notably the non-tag parts are only present when on a non-tag commit. i.e. it will output the correct format for releases.

Unfortunately rust does not have a way of handling this out of the box. The formal position is that the Cargo.toml version field is explicitly for package manifests i.e. for crates.io publishing reasons. And what we want is closer to a "marketing version". See this thread for the discussion(s)..

The linked comment showcases a manner in which to achieve this. Namely to inject an environment variable at compile time with build.rs which is then used by clap et al.

I've previously used vergen for this purpose.

ssm-command exit codes

Another issue is that ssm-command takes the final command's exit code as the entire sets exit code. This is because ssm essentially executes them as a single script but notably without anoption to set -e. Two possible solutions:

1. Only allow single command per ssm-command - not really possible to enforce, or
2. Wrap each command in an if err -> exit as suggested by ssm docs

Honestly what a terrible design :/.

tasks

• Create deploy action
• Create package action
• Make ssm-command robust
• Rework deploy triggers
• Improve version strings #493

An example of the overall "flow" can be seen in the mirko-devops-testing branch. Though it should take the actual implementations of deploy/ssm-command etc from next.

Follow up of #405.

[bobbinth]

Should we try to do this as a part of v0.6 milestone or tackle it in v0.7 milestone?

[Mirko-von-Leipzig]

Should we try to do this as a part of v0.6 milestone or tackle it in v0.7 milestone?

Sooner is better so it gets some usage, but given that we can just test run with devnet its not that critical. So long as we have the packages built, manual deployment also becomes rather easy.

My current strategy is to just do parts of this as I have downtime or as alternate when I have brain fatigue.