Expose Integration Tests as a callable GH artifact

[sreuland]

What problem does your feature solve?

RPC's integration tests are not easily runnable from other gh repository CI workflows.

The integration tests are internalized in the repo and requires several steps for a host to run them, using stellar-rpc.yml as reference host:

• can only by invoked by checking out repo source code to a working copy on a host
• host must run the tests from golang which then performs significant boilerplate setup(infrastructure.NewTest) to establish a running core watcher node using docker compose.
• host must have a compatible core binary installed which matches the version used for watcher node.

What would you like to see?

A new GH callable artifact(either a workflow or action) is created in stellar-rpc repo which invokes the Integration tests.
Other GH repos use the GH callable artifact to run the tests with minimal input parameters, namely two: core version and rpc version.

• Determine whether the GH callable artifact should be an Action or a Workflow.
• Decide whether the new GH callable artifact is allowed from only Stellar org or public repos also.

Implementation concerns:

• refactor stellar-rpc.yml to the new GH callable artifact and stellar-rpc.yml becomes thin CI client to invoke it.
  • evaluate if worthwhile to integrate Quickstart callable workflows to build and run its image for the watcher core and the rpc used in the GH artifact implementation.
    • this would enable skipping docker compose/containerization in infrastructure.Test as would point the integration test rpc client at the rpc port in quickstart container.

What alternatives are there?

Other GH repos that want to run rpc integration tests must checkout the repo and manually do the same setup steps as stellar-rpc.yml.

[leighmcculloch]

A new GHA action

It might make sense for this to be a callable workflow rather than an action. It'll be easier to port an existing workflow to be also callable. And a workflow can control the runner type, use things like matrix strategies internally, and utilise multiple jobs.

[sreuland]

A new GHA action

It might make sense for this to be a callable workflow rather than an action. It'll be easier to port an existing workflow to be also callable. And a workflow can control the runner type, use things like matrix strategies internally, and utilise multiple jobs.

good point, added this determination of callable type to the scope.

[sreuland]

@Shaptic , if possible we should try to schedule for this to get pointed on next planning. it will enable faster-safer group to have some visibility on the effort needed. cc - @sisuresh