-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GitHub and GitLab OnPremise #156
Comments
Thank you for the input!
|
Hi Devin, It was definitely an adventure, started on opentelemetry-collector-contrib to identify every kind of receiver that can be used to analyze CI troubles and produce a status dashboard. We tried to use your Git Provider Receiver as defined inside the contrib repository but we had trouble to run it ... From the chat open-telemetry/opentelemetry-collector-contrib#22028, we knew the development got a sponsor and work is in progress, so we tried the docker image from the upstream referenced here : But because you are really in early development stages and as I understood you are working on refactoring, the last available image runnable on our k8s did not worked as expected, even with GitHub.com (ghcr.io/liatrio/liatrio-otel-collector:0.28.0-386). So, we are looking forward for new version to try with our on premise GitHub Enterprise. ;-) Best regards, |
I cannot thank you enough for this input, Laurent! I'll bring this back to our team and we'll make sure to address these issues for you :) |
@LaurentMarchelli awesome, thank you for sharing! Yea, since it's in development, it won't be published in their release until we contribute more code & update it to alpha. We have a demo of the collector in how to configure it in the https://github.com/liatrio/o11y-demo repo. It's basically the OTEL demo but focused on git metrics with some dashboards to reflect them. I'm in the OTEL slack workspace if you ever want to reach out there for faster conversation & huddle on it! Would be happy to chat anytime. Can I ask what didn't work on your k8s deployment with regular git for the 0.28.0 version? Also, I'm picking this task up right now to enable custom URLs through the default endpoint config. Should be done shortly. |
Hi guys, Thanks for the detailed information, I will definitely take a look at the demo and the latest configuration changes. As the version 0.29.0 is now published I will try it soon on GitHub.com with a token. (ghcr.io/liatrio/liatrio-otel-collector:0.29.0-386)
|
@LaurentMarchelli - just published The So config should look like this: receivers:
gitprovider:
initial_delay: 1s
collection_interval: 60s
scrapers:
github:
github_org: myfancyorg
endpoint: "https://selfmanagedenterpriseserver.com"
tls:
insecure: false
insecure_skip_verify: true
auth: .... |
Hi @adrielp, It’s great, thanks to your latest changes, version 0.30.0 now works with version 3.8.1 of Gitlab Enterprise on-premises. Guys, you rocks ! Just one point: during initial testing, it didn’t work because the program added the path /graphql to the endpoint and I’m not sure it’s best practice because:
And I would have prefered to use : endpoint: "https://ghetest.mycompany.grp:443/api/graphql" Instead than endpoint: "https://ghetest.mycompany.grp:443/api" Here is my working configuration (anonymized): config.yaml ---
extensions:
bearertokenauth/github:
token: "ghp_************************************"
receivers:
gitprovider:
# https://github.com/liatrio/liatrio-otel-collector/blob/main/pkg/receiver/gitproviderreceiver/README.md
# https://github.com/liatrio/liatrio-otel-collector/blob/main/pkg/receiver/gitproviderreceiver/documentation.md
# initial_delay: 1s
# collection_interval: (default = 30s)
initial_delay: 1s
collection_interval: 60s
scrapers:
github:
# https://github.com/open-telemetry/opentelemetry-collector/blob/main/receiver/README.md
# https://github.com/open-telemetry/opentelemetry-collector/tree/main/config/confighttp
# https://github.com/open-telemetry/opentelemetry-collector/blob/main/config/configtls/README.md
github_org: "target_organization"
endpoint: "https://ghetest.mycompany.grp:443/api"
tls:
insecure: false
insecure_skip_verify: true
auth:
authenticator: "bearertokenauth/github"
metrics:
git.repository.count:
enabled: true
exporters:
logging:
verbosity: detailed
service:
extensions: [bearertokenauth/github]
pipelines:
metrics:
receivers: [gitprovider]
exporters: [logging] Thank you very much, we stay in touch for further feedbacks. Laurent Marchelli |
@LaurentMarchelli thanks for trying it and the feedback! I can make a quick fix to auto append The receiver would have to make multiple calls per repo going back in time for the entire commit history of the main branch, create a unique list of users, and then count them to be able to do that through graphql. |
Thanks for the explanation, now it makes sense. I will focus on metrics now. Laurent |
Ok, thanks! Going to go ahead and close this as done. Will open another piece of work to improve the endpoint handling & document the default reasoning. |
Hi guys,
Your work looks promising !!!
However, is it reserved for official GitHub and Gitlab instances or "On Premise" instances will be supported as well with the appropriate configuration ?
For instance :
config.yaml
The text was updated successfully, but these errors were encountered: