doc(readme): list latest layer versions

[serkan-ozal]

With this PR, latest layer versions are fetched from Globadge as badge in SVG format. README provides the Github API URL and JQ expression to the Globadge API to resolve the latest layer versions from raw Github API response.

[pragmaticivan]

It might be a problem where I am, but the Node.js one is always resolving to a broken image.

[maxday]

@pragmaticivan Node.js badge is showing correctly for me while accessing this url using chrome (v136.0.7103.48): https://api.globadge.com/v1/badgen/http/jq?httpURL=https%3A%2F%2Fapi.github.com%2Frepos%2Fopen-telemetry%2Fopentelemetry-lambda%2Freleases&messageExpression=first%28.%5B%5D.tag_name%20%7C%20select%28.%20%7C%20startswith%28%22layer-nodejs%22%29%29%29%20%7C%20split%28%22%2F%22%29%20%7C%20.%5B1%5D%20%7C%20sub%28%22%5C%5C%5C%5C.%22%3B%20%22_%22%3B%20%22g%22%29&label=NodeJS

[serkan-ozal]

It is causing by the Github API rate limiting which is called by Globadge over the given URL. I have improved caching, but this intermittent problem might still happen. Let me check what can I do (there are a few things I can do).

[serkan-ozal]

And converted the PR to draft, so, let's do not merge this PR yet

[serkan-ozal]

Hi,

I have added two new APIs to the Globadge:

• HTTP Badge Config Save API: By PUT request, HTTP badge configs (url, headers, expression, label, etc ...) are passed in the body and Globadge returns created config id for the passed HTTP badge configs.
• HTTP Badge Generate API by Config Id: By GET request, instead of passing all HTTP badge configs in the query params individually, saved config id is passed in the path and the generated badge is returned in the SVG format.

To overcome Github API rate-limiting issue, I have created a fine grained Github token with minimum permissions and created HTTP Badge Configs for each layer (collector, nodejs, python, java-agent, java-wrapper, ruby) by using the fine grained Github token in the HTTP headers config (Authorization: Bearer ...).

So, now, we have 5000 API request limit per hour (https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api) and with the 5 minutes caching (both client side with Cache-Control response header and server side with Redis) period, we should be safe from being throttled by Github.

cc @tylerbenson @maxday @wpessers @pragmaticivan