quality: parameterize branch names and make test

[typotter]

🎟️ Fixes FF-3092 towards FF-3085

👯‍♂️ Related PRs

• sdk-test-data#58
• java-server-sdk#75
• python-sdk#65

Motivation

Changes are often made to the sdk-test-data repository to capture new behaviours, bugs and edge cases. When these changes are pushed to main, the SDKs are cloned locally (locally to the github action running) and their respective tests are run. These tests are set up and run by copies of the SDK test workflows - see sdk-test-data workflow. There are a number of limitations to this setup:

• Test steps are copied from the SDK’s respective workflows; changes to the SDK test workflows need to be replicated in sdk-test-data and this is not obvious to devs
• The SDK tests are not able to run against in-flight changes to sdk-test-data
• When new test-data is committed that breaks an SDK, that breakage is not surfaced in the SDK’s repository until some action triggers its testing workflow (on demand, on pull-request, etc.).

Description of Changes

This change
🚀 - Each SDK's testing workflow is enhanced into a reusable workflow, exposing parameters for SDK branch and the sdk-test-data branch to use in testing.

• The test workflow runs using the main branch of sdk-test-data on all main pushes and Pull Requests using the PR's branch

External to this Change
sdk-test-data get two testing workflows.

1. ♻️ "Local Testing"- For all pull request changes, the "Local Testing" workflow calls the reusable SDK workflows, test results are recorded only in the sdk-test-data action. This is run using the main SDK branch and the "current" branch of workflow, i.e. the pull request branch. (SDK repo does not see/is not notified of test failures during PR lifecycle, only on push to main)
2. ♻️ 🧑‍💻 "Remote Testing" - On all pushes to the main branch of sdk-test-data, the SDK testing workflows are triggered to run within their respective repositories, alerting all subscribers of failed runs (repo is red/green).

[greghuels]

Do we want a fallback to main here? I would think merges to main would be covered by github.ref_name, wouldn't it? If that's the case, it might make sense to throw an error if inputs.sdk_branch || github.head_ref || github.ref_name result in an empty $SDK_BRANCH_NAME since that would indicate something was wrong with the configuration.

[typotter]

You are right that the main fallback here is superfluous. Looking at Actions/checkout readme and code, the ref will be computed as the triggering branch or the default branch if ref is omitted or is a blank string.

The checkout action will throw an error when the refspec doesn't exist, stopping the workflow and displays an error message indicating as much. I'm not sure throwing our own error here would add much, to be honest, but I am trying to get these all hooked up so I can move on to the SDK packaging and integration testing so I may be biased.

[greghuels]

The checkout action will throw an error when the refspec doesn't exist

Ah, right. This is a good callout. Okay, cool.

[greghuels]

Looking great so far! Nothing blocking - just a question about falling back to 'main'