Basic RSS support

[dfrrt5r6uyfrt]

Add an RSS feed for

• Repo (RSS/Atom support for Repos #19055)
• User (Add RSS/Atom feed support for user actions #16002)
• Organisation (RSS/Atom support for Orgs #17714)

[bkcsoft]

This is needed for Activity-log API so #64

[bkcsoft]

gogs/gogs#2301

[Pofilo]

+1

[bkcsoft]

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 :)

[stevenroose]

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.

[stale]

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.

[SamWhited]

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.

[MarkusAmshove]

A RSS feed for /notifications would also be really handy and might solve some of the proposed features if you're watching a repository.

[nickho]

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.

[immanuelfodor]

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.

[SoulSeekkor]

+1

[6543]

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?

[Pofilo]

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.

[6543]

A new RSS entry for each commit ? - what about repo "Activeties" ?

[Zocker1999NET]

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

[mpldr]

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

[bendem]

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.

[mxmilkiib]

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).

[6543]

#16002 (comment)

for those looking for this issue - please look at ☝️

[6543]

update: user now supported, org next (wip)

[mxmilkiib]

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).

[6543]

pull for org support is ready to test ... -> #17714 merged

[6543]

-> #19055

[6543]

to extend this ... -> #19071