Feature Request: Release with Gitea Instances #4040

Closed 6543 closed 6 months ago

Gitea Release (latest by date): | | /gitea/:instance/v/release/:user/:repo

Hi @6543! Can you provide some more detail on the intent of this issue? Are you requesting a new badge be supported in Shields, to provide a Release Version badge for Gitea?

Hi @6543! Can you provide some more detail on the intent of this issue? Are you requesting a new badge be supported in Shields, to provide a Release Version badge for Gitea?

Hi @calebcartwright jes, I would realy like souch a feature!

Thanks! Could you also provide info for the following questions/items:

Is there a public API?
Does the API require an API key?
Link to the API documentation.

public API

as fare as I understand they use swagger to show the current API:

https://gitea.com/api/swagger

to get the release swagger tells me:

curl -X GET "https://$instance/api/v1/repos/$user/$repo/releases" -H "accept: application/json"

you can test it on my instance for example: curl -X GET "https://code.obermui.de/api/v1/repos/6543/remaster/releases" -H "accept: application/json"

and to get only the latest: curl -X GET "https://code.obermui.de/api/v1/repos/6543/remaster/releases?page=1&per_page=1" -H "accept: application/json"

require API key?

only for private repos wich are not public

API docu

https://docs.gitea.io/en-us/api-usage/

I found a solution, but i think gitea is worth adding to the official api. Or?

Solution: [![Release](https://img.shields.io/badge/dynamic/json.svg?label=release&url=https://code.obermui.de/api/v1/repos/6543/remaster/releases&query=$[0].tag_name)](https://code.obermui.de/6543/remaster/releases)

but i think gitea is worth adding to the official api

I agree. It makes it easier for others to leverage the badge without having to include those long queries

need this

The above solution indeed works if the repo is public, for private access, the URL requires token=.. in the query.

How difficult it would be to add gitea_token to the private variable lists? Similar to how drone_token works.

When you're using the dynamic badge you should be able to submit any params you want in the url param but you need to urlencode them so the URL above is better thought of as

https://img.shields.io/badge/dynamic/json.svg?label=release&url=https%3A%2F%2Fcode.obermui.de%2Fapi%2Fv1%2Frepos%2F6543%2Fremaster%2Freleases&query=$[0].tag_name

and then if you wanted the upstream URL to be

https://code.obermui.de/api/v1/repos/6543/remaster/releases?foo=bar rather than https://code.obermui.de/api/v1/repos/6543/remaster/releases then you can call

https://img.shields.io/badge/dynamic/json.svg?label=release&url=https%3A%2F%2Fcode.obermui.de%2Fapi%2Fv1%2Frepos%2F6543%2Fremaster%2Freleases%3Ffoo%3Dbar&query=$[0].tag_name

so you should be able to pass a token (or any other URL param) when using the dynamic badge already.

That said, please be careful.

When we add services which allow the user to pass a token, we only do this where is is possible to generate a stats-only or read-only token. We never want to encourage users to expose a token that allows any high level of privilege to a resource via badge URLs. Obviously with the dynamic badges you can call any URL you want but be careful not to expose a token that allows write access to your repo for example. Consider what level of access a token would allow a malicious actor before passing it to us in a URL param and use an appropriately scoped token :)

@chris48s Thanks for the in-depth explanation, I figured it out mostly, but the https://code.obermui.de/api/v1/repos/6543/remaster/releases?foo=bar example I didn't know! I used ? instead of %3F and it worked.

The problem I have at the moment is that Gitea offers full access token, so not possible to generate a read-only token! A work-around solution would be: create a new user, generate and use its token, and add him as a collaborator with read-only access to all repos.

Gitea offers OAuth2.0, do you have any idea how I can configure Shields to make use of this? Maybe a tutorial or an example (e.g. drone docs - step 1) on how to do it?!

For the dynamic badge approach whatever token you use would have to be a token you are happy to expose.

Gittea does seem like a good candidate for us to add a proper integration for though. Then we could support badges for public instances on shields.io and allow users who self host a shields instance to configure authentication (similar model to bitbucket). If anyone is interested on working on a PR for it we have a tutorial at https://github.com/badges/shields/blob/master/doc/TUTORIAL.md and we'd be happy to review a PR for it.

I looked through the tutorial and it looks really well explained! Kudos for it! I have experience with Java and I will give it a try to implement the service and learn JavaScript along the way.

But before I start, I would like to know if I can follow the github OAuth2.0 model implementation for the Gitea service (gitea supports OAuth2). I read here that for GitHub token persistence you use Redis DB, could I use the same approach or you would recommend something different?

The reason we use redis to store github tokens in production is because shields.io does many more than 5,000 requests per hour to the github api, so we needs to manage a poool of lots of github tokens. For self-hosting scenarios this is unnecessary.

For self-hosting the normal method is the user supplies credentials (username/password/token/key/etc) in environment variables. For examples of how this works for other services we integrate with, see https://github.com/badges/shields/blob/master/doc/server-secrets.md and you can look at the code for the corresponding services to see how they work.

There are auth helpers for

HTTPS Basic Auth
Bearer Authorization Header
Auth passed in Query String

in https://github.com/badges/shields/blob/master/core/base-service/auth-helper.js so those are the easiest methods to work with.

Does anyone know how to get the number of contributors, or the number of closed issues.

I figured out how to do stars count, last commit date, and issues count, but I could not figure out those other two.

Also on the last commit date, is there any way to return just the year-month-day without the actual timestamp... (or even better make it like the github/gitlab commit date with the color coding, etc)

# [![Stars](https://img.shields.io/badge/dynamic/json.svg?label=stars&url=https://git.42l.fr/api/v1/repos/42l/rs-short&query=stars_count)](https://git.42l.fr/42l/rs-short)
# [![Commit](https://img.shields.io/badge/dynamic/json.svg?label=commit&url=https://git.42l.fr/api/v1/repos/42l/rs-short&query=updated_at)](https://git.42l.fr/42l/rs-short)
# [![Issues](https://img.shields.io/badge/dynamic/json.svg?label=issues&url=https://git.42l.fr/api/v1/repos/42l/rs-short&query=open_issues_count)](https://git.42l.fr/42l/rs-short/issues)

If someone is looking for a service to contribute, this would be a really good choice to work on.

It is totally in line with the kind of badges we seek to provide and we've seen a decent amount of interest in this from the community across this thread, https://github.com/badges/shields/issues/8991 and https://github.com/badges/shields/discussions/9494

@chris48s I've had a basic version working on my homelab since around May. Only have releases/language counts added so far as that's all I needed. Just updated it to the latest version of shields and pushed to git.

https://github.com/CanisHelix/shields/tree/4040-gitea

Will do a PR once added a few more (and made it cleaner). Unless there is a tag to apply that it's still WIP.

Thanks to @CanisHelix We now have pretty comprehensive suite of gitea badges:

forks
issues
languages count
last commit
pull requests
releases
stars

compatible with gitea, codeberg, forgejo and public self-hosted instances of any of those platforms :tada:

I'm going to close this issue. Any further badge requests related to gitea are a new issue.

That is awesome! will test it out soon!

badges / shields