[receiver/gitlab] add tracing via webhook skeleton #36838
Conversation
| @@ -226,6 +226,7 @@ receiver/filestatsreceiver/ @open-telemetry/collector-cont | |||
| receiver/flinkmetricsreceiver/ @open-telemetry/collector-contrib-approvers @JonathanWamsley | |||
| receiver/fluentforwardreceiver/ @open-telemetry/collector-contrib-approvers @dmitryax | |||
| receiver/githubreceiver/ @open-telemetry/collector-contrib-approvers @adrielp @andrzej-stencel @crobert-1 @TylerHelmuth | |||
| receiver/gitlabreceiver/ @open-telemetry/collector-contrib-approvers @adrielp @atoulme | |||
There was a problem hiding this comment.
I think you and I have talked about this on the side, but after this contribution goes through and you go through getting added as an OpenTelemetry member, it'd be great to have you added to the list of code owners for this receiver.
There was a problem hiding this comment.
Since this is my first bigger PR, I wasn't sure if that's already enough to become a member. So I thought I would update the code-owners with a subsequent PR once this one is merged and I became a member.
If I can become a member already now, I'm happy to update the code-owners right away as I plan to own/maintain this component. What are your thoughts on this?
There was a problem hiding this comment.
Yup, updates in the next Pr sound good! And you can go ahead and open up the community issue to request to join now.
receiver/gitlabreceiver/config.go
Outdated
| Secret string `mapstructure:"secret"` // secret for webhook | ||
| } | ||
|
|
||
| type RequiredHeader struct { |
There was a problem hiding this comment.
I've been thinking about this for the GitHub receiver as well, but I think this should be converted to RequiredHeaders of map[string]string so that a user can set any set of headers that are required. The main one that would be useful for GitLab would be X-Gitlab-Instance. But if a user has a WAF sitting in front of the receiver (which they should anyway for public traffic) then they can set additional headers of their own choosing.
For the other headers listed in the doc, I think we should map these internal to the receiver.
Description
This PR adds the structure and trace skeleton for a new and already accepted Gitlabreceiver. (thanks @atoulme for sponsoring this!)
The Gitlabreceiver aligns very closely with the Githubreceiver and this PR mostly mirrors the change from this PR: #36632
I'm working together with @adrielp on building out the Gitlabreceiver. More PRs to introduce metrics and actual tracing functionality are about to follow with subsequent PRs.
Link to tracking issue
#35207
Testing
Added basic tests and built the component to test that the health check endpoint, when tracing is enabled, operates correctly.
Documentation
Docs how to configure the Gitlabreceiver via webhooks have been added. While the Gitlabreceiver can be configured after this PR, it will not actually do anything since it is under development and just the skeleton PR.