gitlab-ci: Surface failed GitLab job traces in the Actions log on failure#28
gitlab-ci: Surface failed GitLab job traces in the Actions log on failure#28diaconuccalin wants to merge 2 commits into
Conversation
…lure On pipeline failure, fetch the traces of failed GitLab jobs via the API and tail them into the GitHub Actions log, grouped per job, so failures can be debugged without direct GitLab access. Untrusted trace content is wrapped in ::stop-commands:: with a random token. The API token is passed via a 0600 curl config file rather than argv, and trace filenames are suffixed with the job id to avoid collisions between same-named jobs. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Xeratec
left a comment
Xeratec
left a comment
There was a problem hiding this comment.
Looks good! I just have one change and one request. Would it be possible to test this action in one of your repos, like MAGIA? I believe this would be possible by tagging the commit directly.
For example, the workflow could use:
uses: diaconuccalin/pulp-actions/gitlab-ci@error_log_expose
or, for the specific commit:
uses: diaconuccalin/pulp-actions/gitlab-ci@ac8a2e13f0f99bef678224f61fe7cf1b65575a08
|
|
||
| Optional inputs controlling the Gitlab API version and timeouts are available; see `action.yml`. | ||
|
|
||
| On pipeline failure, the action automatically fetches the traces of failed GitLab jobs and tails them into the GitHub Actions log (grouped per job), so you can see what went wrong without leaving the Actions UI and without needing personal access to the GitLab instance (the traces are fetched using the same mirror `token` the action already uses). Only the last 200 lines of each job's trace are printed (the failure is usually at the end); see the full trace in GitLab or adjust the parameter in the .yml if you need more context. |
There was a problem hiding this comment.
tail -n 200 is hardcoded in action.yml, so there's no input for it. Please expose it as an input (e.g. trace-tail-lines, defaulting to 200).
|
I think this feature should be opt in. One of the reasons why we do have an internal Gitlab CI is to shield sensitive information from the public e.g. technology information. |
Point the workflow at the fork commit under review in pulp-platform/pulp-actions#28, which internalises error log fetching and display into the reusable action. Remove the now-redundant inline steps from this repo. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Hey @Xeratec, here it is, a CI run with a failure meant to surface the error log. |
Add `expose-error-logs` (default: false) to avoid leaking sensitive trace content by default, and `trace-tail-lines` (default: 200) to make the tail length configurable. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
3 participants
Summary
gitlab-ciaction now fetches the traces of failed GitLab jobs via the API and tails the last 200 lines of each into the GitHub Actions log, grouped per job — so failures can be debugged without direct access to the GitLab instance, using the same mirrortokenthe action already uses.::stop-commands::with a random token, so lines like::error::in a trace are printed literally rather than interpreted as workflow commands.curlvia a0600config file (-K) rather than on the command line, keeping it out of argv/ps.if: failure()and the script always exits 0, so it can never turn a green run red or mask the real failure.