-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Feature Request: Release with Gitea Instances #4040
Comments
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:
|
public APIas fare as I understand they use swagger to show the current API: to get the release swagger tells me:
you can test it on my instance for example: and to get only the latest: require API key?only for private repos wich are not public API docu |
I found a solution, but i think gitea is worth adding to the official api. Or? Solution: |
I agree. It makes it easier for others to leverage the badge without having to include those long queries |
This comment has been minimized.
This comment has been minimized.
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? |
When you're using the dynamic badge you should be able to submit any params you want in the 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 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 The problem I have at the moment is that Gitea offers full access token, so not possible to generate a read-only token! Gitea offers OAuth2.0, do you have any idea how I can configure Shields to make use of this? |
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:/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:/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
in https:/badges/shields/blob/master/core/base-service/auth-helper.js so those are the easiest methods to work with. |
@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:/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:
compatible with gitea, codeberg, forgejo and public self-hosted instances of any of those platforms 🎉 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! |
Gitea Release (latest by date): | | /gitea/:instance/v/release/:user/:repo
-> https:/go-gitea/gitea
The text was updated successfully, but these errors were encountered: