exp/services/rpc-soroban: packaging and releases

[sreuland]

What problem does your feature solve?

identify the packaging and release process for soroban-rpc

What would you like to see?

unique release numbering for soroban-rpc vs. that of horizon
ability to generate new/promote existing soroban-rpc deb pkgs from jenkins job similar to stellar-horizon-package-builder-new

What alternatives are there?

current day quickstart uses branch/label reference to a version of soroban-rpc source code and then builds that and installs that into quickstart, this is non-standard, and makes clients like quickstart more brittle, as they have to reference source code tag/branches instead of release bin versions.

[sreuland]

in short term, I created tag https://github.com/stellar/go/releases/tag/soroban-rpc-v0.0.1-alpha, to facilitate quickstart having a steady reference to version of soroban-rpc for now.

[sreuland]

@tamirms , I was going to start this unless you want to take it, or think it should hold off?

am thinking the net changes would be:

• new jenkins job stellar-soroban-rpc-package-builder-new to build stellar-soroban-rpc_<ver>-<build_no>
• add release tag hook to .github/workflows/soroban-rpc.yml
• update quickstart to reference soroban-rpc deb pkgs instead of source tag/branch

let me know if any concerns or I'm missing something needed for soroban-rpc?

[sreuland]

changes are in ops repo/PR's:

deb pkg - stellar/packages#183
jenkins job - https://github.com/stellar/pipelines/pull/470