Track the (git) repository address

[hatchan]

Just as we currently track the commit and branch in the build_info metric, it would be useful for this metric to also include the git repository address. This could be useful for consumers of the metrics.

The implementation would just be a simple label on the build_info metric.

Examples

A user has autometrics setup for their application and are being scraped. These metrics will now also include the repository address. While viewing the metrics for specific function in the explorer, they can easily open their repository since explorer was able to retrieve the repository address from the metrics.

A deeper integration could be with explorer and the GitHub application. If you were to look at a specific function within explorer, you can open a deep link to the correct file and line/column within the file for a specific branch.

Considerations

It should be made easy to automatically add this information, but it should also be possible to manually set this

Not every user wants to expose this information as this could be considered private, so there should be a way to opt-out (if it is done automatically).

What will go into the key? I think it makes sense to have it just be the git address. So this means it can be a ssh or http endpoint with every possibility as the domain and path. This means that the explorer is responsible to parse and inspect the domain to see if they offer higher level support (ie. if the is github.com then we can create a specific deep link).

Is there anything in the OTEL specification which covers this something like or similar to this? Does it make sense to reuse a certain label key that OTEL is using for example.

[arendjr]

I think storing the Git URL makes sense indeed.

I'm not aware of an OTEL way of storing that, but a quick search did reveal the following: https://github.com/open-telemetry/semantic-conventions/blob/main/docs/general/attributes.md#source-code-attributes
It's not exactly the same, but still interesting to consider for our use cases.

[hatchan]

Those source code attributes could be useful, but they would be applied on a function metric itself, instead of the build_info.

[flenter]

From my past working experience, I would say I would like to know not only the URL, but also the provider type (i.e. github, bitbucket, gitlab or something else). Because if we get URLs that don't match the typical hosted solutions it's tricky to create the right deeplink URL from our dashboard.

[hatchan]

I think we can put in a hint, I guess. But we need to handle that this field is going to be empty.

For example when a user has their source control repo url to something like git@github.com:autometrics-dev/am, then we can easily see that this is of source control is of "type": github. But if the user has a custom domain, then the library cannot determine that this is a self hosted github instance. The only way to support this is for the user to specify this manually (either through a envvar or a initialization fn).

Further more, do we allow the user to specify any value in the "type" label? Or are we going to restrict the user only use a few predefined values?

[flenter]

Interesting. I mostly approached this from a front-end/explorer perspective. I think it would be good to be able to specify a value for the "type" label. Just so it can provide a hint to a front-end that's reading the data from prometheus and wants to provide links to the source code/commit.

[brettimus]

just for the sake of having a record, i entertained the idea of (alternatively) a gauge that maps the service name to the remote repository.

# HELP service_info The mapping between service name and repository location
# TYPE service_info gauge
service_info{service_name="animals-api",provider_type="github",address="https://github.com/autometrics-dev/autometrics-demo-python-fastapi-animals"} 1

however, i don't think this carries any unique benefit, and it would make the query slightly more involved.

so thumbs up for the og benno proposal 👍

[hatchan]

We already have the service name in the build_info metrics, so there isn't any advantage of putting it in a different metrics, it actually make some queries more complicated since you now have to join three metrics.

[hatchan]

I did manage to find a reference to a code.url, but that was never merged into the OTEL spec: open-telemetry/opentelemetry-specification#2672

[hatchan]

I've created an spec update for this, see: #88

[hatchan]

This will be part of v1.0. See #88