Generate link to matrix job #18
Assignees
Comments
lawrence-forooghian
added a commit
that referenced
this issue
Dec 14, 2023
Currently, the observability server UI links to the workflow run attempt that performed the upload. This is fine in the case where the workflow only contains a single job, as it did in ably-cocoa. But in the case where there’s more than one job in a workflow (e.g. in the case of a matrix build), there’s no way to tell which job an upload corresponds to. So, include this information in the upload. Resolves #18.
lawrence-forooghian
added a commit
that referenced
this issue
Dec 14, 2023
Currently, the observability server UI links to the workflow run attempt that the upload corresponds to. This is fine in the case where the workflow only contains a single job, as it did in ably-cocoa. But in the case where there’s more than one job in a workflow (e.g. in the case of a matrix build), there’s no way to tell which job an upload corresponds to. So, include this information in the upload. Resolves #18.
lawrence-forooghian
added a commit
that referenced
this issue
Dec 14, 2023
Currently, the observability server UI links to the workflow run attempt that the upload corresponds to. This is fine in the case where the workflow only contains a single job, as it did in ably-cocoa. But in the case where there’s more than one job in a workflow (e.g. in the case of a matrix build), there’s no way to tell which job an upload corresponds to. So, include this information in the upload. Resolves #18.
lawrence-forooghian
added a commit
that referenced
this issue
Dec 14, 2023
Currently, the observability server UI links to the workflow run attempt that the upload corresponds to. This is fine in the case where the workflow only contains a single job, as it did in ably-cocoa. But in the case where there’s more than one job in a workflow (e.g. in the case of a matrix build), there’s no way to tell which job an upload corresponds to. So, include this information in the upload. Resolves #18.
lawrence-forooghian
added a commit
that referenced
this issue
Jan 10, 2024
Currently, the observability server UI links to the workflow run attempt that the upload corresponds to. This is fine in the case where the workflow only contains a single job, as it did in ably-cocoa. But in the case where there’s more than one job in a workflow (e.g. in the case of a matrix build), there’s no way to tell which job an upload corresponds to. So, include this information in the upload. Resolves #18.
lawrence-forooghian
added a commit
that referenced
this issue
Jan 10, 2024
Currently, the observability server UI links to the workflow run attempt that the upload corresponds to. This is fine in the case where the workflow only contains a single job, as it did in ably-cocoa. But in the case where there’s more than one job in a workflow (e.g. in the case of a matrix build), there’s no way to tell which job an upload corresponds to. So, include this information in the upload. Resolves #18.
lawrence-forooghian
added a commit
that referenced
this issue
Jan 22, 2024
Currently, the observability server UI links to the workflow run attempt that the upload corresponds to. This is fine in the case where the workflow only contains a single job, as it did in ably-cocoa. But in the case where there’s more than one job in a workflow (e.g. in the case of a matrix build), there’s no way to tell which job an upload corresponds to. So, include this information in the upload. I originally tried implementing this by passing a job-index input, whose value was the index to which the current job corresponds in the response from the "list jobs for a workflow run attempt" GitHub API. However, some experimentation then showed that that the order in which the jobs are listed in the action YAML file doesn’t necessarily match that in which they are returned from the API, so there was no way to calculate the value to pass for job-index. Hence, switched to using the job’s `name` instead. Resolves #18.
lawrence-forooghian
added a commit
that referenced
this issue
Jan 22, 2024
Currently, the observability server UI links to the workflow run attempt that the upload corresponds to. This is fine in the case where the workflow only contains a single job, as it did in ably-cocoa. But in the case where there’s more than one job in a workflow (e.g. in the case of a matrix build), there’s no way to tell which job an upload corresponds to. So, include this information in the upload. I originally tried implementing this by passing a job-index input, whose value was the index to which the current job corresponds in the response from the "list jobs for a workflow run attempt" GitHub API. However, some experimentation then showed that that the order in which the jobs are listed in the action YAML file doesn’t necessarily match that in which they are returned from the API, so there was no way to calculate the value to pass for job-index. Hence, switched to using the job’s `name` instead. Resolves #18.
lawrence-forooghian
added a commit
that referenced
this issue
Jan 22, 2024
Currently, the observability server UI links to the workflow run attempt that the upload corresponds to. This is fine in the case where the workflow only contains a single job, as it did in ably-cocoa. But in the case where there’s more than one job in a workflow (e.g. in the case of a matrix build), there’s no way to tell which job an upload corresponds to. So, include this information in the upload. I originally tried implementing this by passing a job-index input, whose value was the index to which the current job corresponds in the response from the "list jobs for a workflow run attempt" GitHub API. However, some experimentation then showed that that the order in which the jobs are listed in the action YAML file doesn’t necessarily match that in which they are returned from the API, so there was no way to calculate the value to pass for job-index. Hence, switched to using the job’s `name` instead. Resolves #18.
lawrence-forooghian
added a commit
that referenced
this issue
Jan 23, 2024
Currently, the observability server UI links to the workflow run attempt that the upload corresponds to. This is fine in the case where the workflow only contains a single job, as it did in ably-cocoa. But in the case where there’s more than one job in a workflow (e.g. in the case of a matrix build), there’s no way to tell which job an upload corresponds to. So, include this information in the upload. I originally tried implementing this by passing a job-index input, whose value was the index to which the current job corresponds in the response from the "list jobs for a workflow run attempt" GitHub API. However, some experimentation then showed that that the order in which the jobs are listed in the action YAML file doesn’t necessarily match that in which they are returned from the API, so there was no way to calculate the value to pass for job-index. Hence, switched to using the job’s `name` instead. Resolves #18.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In the case of a matrix job, the observability server UI doesn't currently display a link to the individual job that caused the upload. Same issue as described in ably/ably-cocoa#1840 (comment). We need to generate the URL inside the action by fetching it from the GitHub API, and include it in the upload.
The text was updated successfully, but these errors were encountered: