[SDK-1683] Single workflow with matrix strategy

[maratal]

Closes #1311

[lawrence-forooghian]

Something that I noticed is that there is now no way to tell which OS an observability server upload corresponds to. Compare the following:

• an upload from before these changes
• an upload from after these changes

Notice that in the first one, clicking the "GitHub run ID" or "GitHub run attempt" link takes you to the iOS job. In the second, it takes you to an overview page that shows all 3 OSs.

There is probably some other piece of data that we need to get from the environment and include in the upload to the observability server to allow it to display a link to the correct job.

[maratal]

Something that I noticed is that there is now no way to tell which OS an observability server upload corresponds to. Compare the following:

* [an upload from before these changes](https://test-observability.herokuapp.com/repos/ably/ably-cocoa/uploads/b12c25dc-c3ac-4912-a6cc-6106ed026267)

* [an upload from after these changes](https://test-observability.herokuapp.com/repos/ably/ably-cocoa/uploads/358cbc52-d669-4e6a-827d-d3ac7f46e685)

Notice that in the first one, clicking the "GitHub run ID" or "GitHub run attempt" link takes you to the iOS job. In the second, it takes you to an overview page that shows all 3 OSs.

There is probably some other piece of data that we need to get from the environment and include in the upload to the observability server to allow it to display a link to the correct job.

Turned out it's not trivial. GITHUB_JOB is actually an alphabetical id ("check" in our case), and to get numerical id one need to use a custom parser action - this for example. Source https://stackoverflow.com/questions/71240338/obtain-job-id-from-a-workflow-run-using-contexts

[lawrence-forooghian]

I think we need to do that then. Sounds like the steps are the following:

1. before uploading to the observability server, fetch the jobs for the current workflow attempt
2. find the currently-running job from the response's jobs array (I believe, according to what this says about the order of job creation, that the $n^{th}$ item there corresponds to the $n^{th}$ item in the matrix, so we can fetch it by using the index of the current job in the matrix, which we might need to pass as an additional variable from the matrix to the job)
3. extract the html_url from that job and upload it as a new parameter (e.g. GITHUB_JOB_URL, I can add support to the server for storing and displaying this value) to the observability server

[lawrence-forooghian]

I've actually just needed to do the same thing for ably-js. Here's the PR for adding this functionality to the upload; it should help you here. ably/test-observability-action#20

[lawrence-forooghian]

I've implemented it for ably-cocoa in #1845. You'll just need to pass the --job-index argument in this PR (in your case it'll be ${{ strategy.job-index }}).

[maratal]

I've implemented it for ably-cocoa in #1845. You'll just need to pass the --job-index argument in this PR (in your case it'll be ${{ strategy.job-index }}).

This is wonderful, thanks Lawrence!

[lawrence-forooghian]

Looks good — let's not merge this until ably/test-observability#76 is merged and deployed though.

[lawrence-forooghian]

Looks good — let's not merge this until ably/test-observability#76 is merged and deployed though.

This is now deployed.

[lawrence-forooghian]

Re-running CI to check that the URL gets correctly populated in observability server. If it does, I'll approve.