New component: Github Actions Receiver

[krzko]

The purpose and use-cases of the new component

The GitHub Actions Receiver processes GitHub Actions webhook events to observe workflows and jobs. It handles workflow_job and workflow_run event payloads, transforming them into trace telemetry.

Each GitHub Action workflow or job, along with its steps, are converted into trace spans, allowing the observation of workflow execution times, success, and failure rates.

If a secret is configured (recommended), it validates the payload ensuring data integrity before processing.

Example configuration for the component

receivers:
  githubactions:
    endpoint: 0.0.0.0:443
    path: /ghaevents
    secret: YourSecr3t
    tls:
      certfile: /path/to/cert
      keyfile: /path/to/key

Telemetry data types supported

traces

Is this a vendor-specific component?

• This is a vendor-specific component
• If this is a vendor-specific component, I am proposing to contribute and support it as a representative of the vendor.

Code Owner(s)

No response

Sponsor (optional)

No response

Additional context

• We are heavy user's of Github Actions and we need to observe our workflows via standard observability back-ends
• We have an initial implementation working, although it's still under development https://github.com/krzko/opentelemetry-collector-contrib/tree/feat-add-githubactionseventreceiver/receiver/githubactionsreceiver
• Emitted trace telemetry is as follows at present:

Multi Job

Matrix Strategy

Deterministic Step Spans

[bryan-aguilar]

hi @krzko,

Thank you for the new component proposal. If you have not already please make sure you review the new component guidelines.

If you have not found a volunteer sponsor yet then I encourage you to come to our weekly collector sig meetings. You can add an item to the agenda to discuss this new component proposal.

[krzko]

Thanks @bryan-aguilar for the heads up.

No sponsor as of yet, so I'll have to add an agenda item for this component and try and make the EU-APAC meeting, as I'm based out of Australia.

[krzko]

Jumped into the Collector SIG (EU-APAC) meeting today, but nobody around 🤷

Not looking forward to do doing a 3AM call for the main SIG meeting.

[bryan-aguilar]

What experience have you had with long running workflows/jobs? We have some workflows that will run for 3+ hours.
Are there any examples of what a trace looks like for jobs that heavily use job matrices? Another scenario my team is in is that we have a one job that will fire off 100+ jobs based on it's matrix config at the time.

[krzko]

Matrix strategies are represented as traces quite well using all the o11y backends that I've uses, so I think this use case is covered.

I use the workflow_run event as the root span, for some long running workflows your o11y backbend might report a missing root span if you view the trace before the workflow run has completed. We emit the root span when status is completed and then we set the span status based on the conclusion.

For the 100+ scenario, that might be a rather large waterfall view, have been toying around with potentially using links, but so far keeping it simple.

[adrielp]

Just curious here @krzko - had you tried the webhook receiver? We were playing around with event logging through GitHub apps leveraging the Webhook receiver from OTEL, but from what I recall, we found two main issues.

1. support for auth extensions
2. flattening of data support in the transform processor

It's been a while, so this is from memory, but curious if you had tried/experimented with that.

Additionally, wondering if you've tried tracing at the runner level instead of event logging to inferring traces after the fact. We had found that in order to accomplish tracing at the runner level we'd have to use env vars as propagators (which isn't in the spec yet, but is currently being looked at as an OTEP) cross workflows.

One aspect of doing it at the runner level is being to see exactly the time the runner starts up, etc.