quality: parameterize SDK and test-data branches

[typotter]

🎟️ Fixes FF-3096 towards FF-3085

👯‍♂️ Related PRs

• sdk-test-data
• react-native-sdk
• golang-sdk
• android-sdk

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).

[aarsilv]

Approving, but give the on: section of the workflow a look

[aarsilv]

should this be restricted to main branch?

[typotter]

This is just a change in syntax to accommodate multiple triggers. That being said, there's not a lot of consistency across the SDKs here on this, so let's set the bar here.
We want tests to run when a) push to main, b) PR opened, c) PR updated
So, you are right that we can restrict push to branches: main as pull_request includes the synchronize event which is triggered by pushing commits to a branch under a PR.

[aarsilv]

do we need to include '**/*' as the paths for this?

[typotter]

I don't believe so. paths provides a way to filter the event trigger and **/* matches everything which is the same as unfiltered.