[sentry-junior]

A smaller take on #73. Like #73, it sends one transaction per workflow run, with a span for each job and a child span for each step, so a run shows up as one trace and not as a flat list of job transactions.

#73 builds the trace from workflow_job webhooks. It buffers jobs in memory and uses timers to guess when a run has finished, which breaks on Cloud Run when there are several instances or an instance restarts. This PR waits for the workflow_run completed webhook and makes one call to list the run's jobs. The app already handles that webhook for commit traces. Nothing is kept in memory and nothing has to be guessed.

Rollout follows the review on #73:

• Job traces don't change, so the current CI dashboards keep working.
• It's off by default. WORKFLOW_TRACES_ORGS=getsentry turns it on for the Sentry org only while we check it.
• The GitHub App needs the Workflow run event subscription. Commit traces already require it.

Known limits:

• A run with more than 100 jobs isn't traced. This matches how commit traces handle more than one page.
• Skipped jobs are left out, as they are for job traces.
• The workflow trace uses a different trace id from the job traces, so the two don't mix in one trace.

via @armenzg.

--

View Session [Sentry]