Job Summaries
Job summaries let a workflow write formatted Markdown that renders directly on the run page. Instead of scrolling raw log output to find out whether a test passed, you get a readable report — tables, headings, checklists, and diagrams — attached to the job that produced it.
Summaries are written by your workflow steps to a file that Copia captures when the job finishes. They are stored on the Copia server and rendered in the web UI. They are not artifacts, so there is nothing to download and nothing to clean up.
Why Use Job Summaries
Any time a workflow produces a result a person needs to read, a summary is a better place for it than the log:
Report unit or validation test results as a pass/fail table rather than console output.
Show which PLC files a run checked, converted, or flagged.
Give reviewers an at-a-glance verdict from the pull request checks, without opening the run.
Publish build metadata — project version, target controller, run duration, file counts.
Document a process or decision path with a Mermaid diagram.
Without a summary, that information is still in the log, but a reviewer has to know where to look for it.
Where Summaries Appear
Opening a run without selecting a job shows the Summary view: run-level details such as the trigger event, who triggered it, status, and total duration, alongside the workflow graph. The graph shows each job, the dependencies between them, and the overall success rate.
Each panel is labeled with the name of the job that produced it. Panels appear in job completion order, so the job that finished first is listed first.
Writing a Summary
Each step gets its own summary file. The path is available in the GITHUB_STEP_SUMMARY environment variable. Append Markdown to that file and it renders on the run page.
On Linux runners
On Windows runners
Windows runners default to PowerShell, where the variable is referenced as $env:GITHUB_STEP_SUMMARY:
Appending, Overwriting, and Clearing
The summary file behaves like any other file, so redirection controls what ends up in it:
echo "text" >> $GITHUB_STEP_SUMMARY
Appends to the step's summary
echo "text" > $GITHUB_STEP_SUMMARY
Replaces everything written by that step
rm $GITHUB_STEP_SUMMARY
Clears the step's summary entirely
These operations only affect the step that runs them. A step cannot modify or clear another step's summary.
They also only apply while the job is running. Once a step finishes, its summary is uploaded and fixed — a later step cannot revise it, and a re-run produces a separate summary rather than editing the original.
How Summaries Are Assembled
Understanding the assembly order helps when a summary does not look the way you expected:
Each step is captured separately. Steps are isolated, so an unclosed code fence or a broken table in one step cannot corrupt the rendering of another.
Steps are concatenated per job. When the job finishes, all of its step summaries are joined in step order into a single job summary.
Jobs are ordered by completion time. On the run Summary view, the job that finished first appears first — which is not necessarily the order the jobs are declared in.
Examples
Conditional pass/fail report
Use if conditions to write a different summary depending on the outcome of an earlier step:
Building a summary across multiple steps
Because step summaries are concatenated in order, you can build up a report as the job progresses:
Labeling matrix legs
Each matrix leg produces its own panel, so include the matrix value in the content to make the report readable on its own:
Mermaid diagrams
Mermaid blocks in a summary render as diagrams:
Supported Formatting
Summaries render GitHub Flavored Markdown, including headings, tables, task lists, fenced code blocks, links, blockquotes, and Mermaid diagrams.
Content is sanitized before rendering. The following are not supported:
Scripts and any form of interactivity.
Custom CSS, including
styleandclassattributes.Images from paths inside the workspace. Images must be reachable at a public URL to display.
Secrets Are Not Masked
Secrets written into a job summary are rendered as plain text. Unlike workflow logs, summary content is not passed through secret masking. Anyone who can view the run can read the summary.
Never write a secret, token, password, or connection string into $GITHUB_STEP_SUMMARY — including indirectly, such as by echoing an entire environment or dumping a configuration file.
If a secret does reach a summary, treat it as exposed: rotate the secret, then remove the summaries from the run as described below.
Removing Summaries
Summary content can be removed from a completed run without deleting the run itself. On the run Summary view, select Remove Summaries at the top right of the summary panels.
This removes the stored summary content for the run. The run itself, its logs, and its artifacts are unaffected — only the rendered summaries are removed.
Removal is permanent. The content cannot be restored, and re-running the workflow produces new summaries rather than recovering the previous ones.
Removing summaries applies to the whole run. Individual job or step summaries cannot be removed on their own.
Use this feature when something that should not be printed to a summary is visibile, like a secret. Once the summary is removed, rotate the secret for security purposes.
Limits
1 MiB per job. The combined size of all step summaries in a job is also capped at 1 MiB.
Over-limit content is truncated, not dropped. When a summary exceeds the cap, the content is truncated and marked in place with Job summary truncated: it exceeded the maximum allowed size. The step and the job both continue normally — an oversized summary never fails a run.
Summaries are not artifacts. They are stored on the Copia server and rendered in the UI only. They do not appear in the Artifacts section, cannot be downloaded, and are not retrievable through the API. If you need the report as a file, write it to disk and upload it with actions/upload-artifact in addition to writing the summary.
Troubleshooting
The Summary view is empty. Confirm that a step actually wrote to GITHUB_STEP_SUMMARY, and that it used >> or > rather than printing to standard output. A step that only runs echo "text" prints to the log, not the summary.
A summary is missing on Windows. PowerShell requires the $env: prefix. $GITHUB_STEP_SUMMARY on its own resolves to an empty value in PowerShell, so the redirect goes nowhere.
A table is not rendering. Markdown tables require a header separator row (| --- | --- |) and a blank line before the table starts. Write the blank line explicitly with echo "".
Last updated
Was this helpful?