New component: GitLab Receiver

[adrielp]

The purpose and use-cases of the new component

The purpose of this receiver is the same as the GitHub Receiver but in the context of GItLab. It will support metrics, logs, and traces from GitLab in almost the same way as the GitLab receiver. Much of this code exists in some form or another.

Really, the logic and metrics are the same as the GitHub receiver. The differences are:

• API Calls are different
• Events that are used to build traces are different

Everything else is closely aligned. The CICD SIG will leverage this as one of the prototypes alongside the GitHub receiver helping to inform conventions and support telemetry in GitLab.

Example configuration for the component

extensions:
  bearertokenauth/gitlab:
    token: ${env:TOKEN}

receivers:
  gitlab:
    interval: 15s #the interval at which the scraper scrapes
    group: mygroup #the organization name in github
    query: <some query>
    traces:
        .... <traces webhook configuration>
    auth:
      authenticator: bearertokenauth/gitlab

Telemetry data types supported

Metrics, Logs, Traces

Is this a vendor-specific component?

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

Code Owner(s)

adrielp

Sponsor (optional)

@atoulme

Additional context

No response

[atoulme]

I will sponsor this.

[niwoerner]

Hi all, thank you for all the great work you've been doing in context of CI/CD pipelines and OpenTelemetry.

I've been playing around with a Gitlabreceiver to create traces for CI/CD pipelines. That isn't exactly aligning with this issue, but since the Gitlabreicever was working pretty well for me, it might be interesting for more folks here in the community.

I'll be giving a talk about this next week at the Kubecon. If someone is present there, please let me know and we can catch up about this topic.

I would be happy to contribute (and maintain) this, if there would be an interest from the community. :)

[adrielp]

Hey @niwoerner , thanks for coming from LinkedIn and posting here on the issue! I think the alignment is quite nice, given the concept on the tracing end is the same. Would love to get support in contributing and maintaining this going forward. Let's sync up & figure out how we can move forward on this!

[abitrolly]

interval: 15s #the interval at which the scraper scrapes

I believe GitLab CLI can subscribe to events from running pipeline.

glab pipeline status --live

#  -l, --live            Show status in real time until the pipeline ends.

So maybe it is possible to receive events using some kind of (web)hook instead of the scraper.

The purpose of this receiver is the same as the #22028 but in the context of GItLab. It will support metrics, logs, and traces from GitLab in almost the same way as the GitLab receiver.

I would appreciate the expanded use cases without redirections to GitHub that may significantly drift away from what is it possible specifically with GitLab.

I will sponsor this.

What pain point do you want to address first?

[adrielp]

@abitrolly - the GitHub receiver is important context. Originally it was named the gitprovider receiver which I originally developed as a prototype here. It scraped both GitLab & GitHub's respective API's to build out a set of VCS Metrics.

Upon reconsideration of the implementation & incorporating other signals (tracing, logs), we as a community decided to separate things out and rename the receiver to be github receiver. While there are implementation differences, the high level concept, and core logic, is much the same. Events(logs) & Traces through Webhook + a set of metrics through scraping.

This is a good summary of the decisions and context I mentioned above.

[abitrolly]

@adrielp I am asking about specific use cases to estimate the scope of work left from https://github.com/niwoerner/gitlabreceiver. Ideally it should be a checkbox list.

• receive pipeline spans in real-time
• receive pipeline spans once run is finished
• ???