Basic RSS support
dfrrt5r6uyfrt opened this issue · 24 comments
+1
If anyone wanna have a go at this, I suggest https://github.com/gorilla/feeds as it's well maintained
EDIT: especially since the Activity API would need Atom feeds :)
I'm very interested in this. I might try to work on this a bit in September/October.
It shouldn't be that hard, right? GitHub has an Atom feed for every repo with commits, releases and tags. Apart from these, I think "issues" (including PRs) and "issues+comments" (including PRs and comments) would make a lot of sense. Do you think splitting Issues and PRs is better than having them combined?
I'd basically like the e-mail notifications (GitHub-style), to be found in an Atom feed.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.
Ping; since this is being marked as stale I'd like to say that I also have a use case for this. As a package maintainer, and someone who creates software, I have a lot of dependencies that I need to keep up with. For dependencies in software and software that I package on Arch, if it is on GitHub I generally subscribe to the Atom feed for "Releases" and "Tags" and if either of those are updated I can update my package, or check if there is a reason to update my dependency. I get a lot of emails, and this is something that I don't need cluttering up my inbox and don't need to reply to, so I prefer to use a feed. It would be nice to be able to do the same thing on Gitea if anyone has the time; and if not, it would be great if this issue could be kept open for future contributors to find.
Thank you for your time and consideration of this feature request.
A RSS feed for /notifications would also be really handy and might solve some of the proposed features if you're watching a repository.
We are currently migrating from Gitblit to Gitea and this is a feature i will miss. It is very handy to monitor actual works on repositories without spaming your inbox.
As Gitea is often self-hosted, it would be great to have separate repo commit and release feeds, otherwise, you need to create an account on every single instance you have a repo to follow. Like Github has "watch only releases" and "watch all" options, but RSS feeds for Gitea as a means of decentralized notifications.
+1
what do you think of: GET gitea.com/user/repo.rss, GET gitea.com/user/repo.atom, GET gitea.com/user.rss and GET gitea.com/user.atom as endpoints?
About GET gitea.com/user/repo.rss and GET gitea.com/user/repo.atom, what will we get ? A new RSS entry for each commit ?
It could be usefull for the ones who want to see every commits.
GET gitea.com/user/repo/releases.rss and GET gitea.com/user/repo/releases.atom would be awesome to have only the entries concerning all new releases.
A new RSS entry for each commit ? - what about repo "Activeties" ?
I would suggest to add an endpoint containing all "activities" like commits / releases / new branches / issues / … and another few for each type (one for "commits on branch xy", one for releases, one for new issues), if this is possible and does not require to much performance
I'd like to suggest to make it GitHub-ish
Releases: https://github.com/go-gitea/gitea/releases.atom
Commits: https://github.com/go-gitea/gitea/commits.atom
I don't really see a need to add additional endpoints to get branches and so on. That's what an API is for. Maybe a way to filter the commits.atom like commits.atom?branch[]=master&branch[]=develop&author[]=poldi1405
How about we provide rss/atom for the places that already exist displaying what's already displayed at those places?
- Commits are currently located at
$repo/commits/branch/$x-> use$repo/commits/branch/$x.rss - Releases are currently located at
$repo/releases-> use$repo/releases.rss - Activity is at
/activity-> use$repo/activity.rss
The only one I'd had is $repo/commits.rss which would serve the same content as $repo/commits/branch/$default_branch.
Content negation could even be used to avoid adding new routes at all, just pass in the correct accept header. Though I understand the use of the extension for ease of use.
It would be nice if Gitea could do what GitHub and GitLab don't yet by providing both date elements as well as separate release and tag feeds.
Edit: I also found this gitea-feed-workaround (Google cache link as source is down).
for those looking for this issue - please look at ☝️
update: user now supported, org next (wip)
N.b. having the [unique] id element for release feeds be something that reflects the release tag/version, something that can be easily parsed, would be very handy. GitHub does this, SourceForge and a few others use a hash, and if there the release title is made hard to parse by a developer (by not including the release number, being inconsistent with formatting, etc.) then there's no happy way to consume/use the feed (and SF feeds also unfortunately mix releases and news posts).