Workflow summary
ximon18 opened this issue · comments
I like the idea of a report added to the workflow summary. I don't know what it should show but leaving users with just the list of artifacts shown by GitHub in the summary seems a bit ... raw to work with?
The mechanism by which such a report would be added is the GitHub job summary functionality. That works by at the job step level writing content to a step specific file. Each step that does this causes a panel to be added to the workflow summary page.
We wouldn't want N panes to be added, preferably just one, so that would require a new post job that runs after the other jobs. At that point the post job won't know what has been done before it, what was created or uploaded where, so earlier jobs would have to make information available to the post job. However there is no mechanism at present in GitHub Actions for a downstream job of a matrix job to collect all of the outputs of the matrix invocations of the upstream job, so data has to be sent somewhere else by the matrix job runs and fetched by the post job.
One way would be to create artifacts with metadata for the post job to download and use (as it can download all artifacts without needing to know their names). Except that you wouldn't want to abuse artifacts in this way as there is (a) no way to delete them (as their final location is not known till the job completes) and (b) that would make the artifact list even noisier and harder to use than it already is.
Another issue is that any summary report cannot link to the artifacts themselves as their location is not known till after the job completes. The download-artifact action used mid-workflow avoids this problem by downloading artifacts from the internal Azure pipeline storage location but this isn't available I think to the workflow jobs and steps themselves, or certainly would be quite a hack to do and for all I know the artifacts are actually taken out of the Azure pipeline storage and placed somewhere specific for GitHub workflow usage at the end of a job, and any links to Azure pipeline locations probably need to be authenticated anyway and such auth could not be safely included in links included in the Markdown summary report text we would generate...
So... I still have the itch that something could be better, but I don't know what or how ... :-)
Here's a screenshot from some testing I did in the job-summaries-test branch:
