Basic RSS support #194

@bkcsoft commented on GitHub (Jan 6, 2017):

This is needed for Activity-log API so #64

@bkcsoft commented on GitHub (Jan 6, 2017): This is needed for Activity-log API so #64

GiteaMirror commented

https://github.com/gogits/gogs/issues/2301

@bkcsoft commented on GitHub (Jan 6, 2017):

@bkcsoft commented on GitHub (Jan 6, 2017): https://github.com/gogits/gogs/issues/2301

GiteaMirror commented

@Pofilo commented on GitHub (Apr 20, 2018):

+1

@Pofilo commented on GitHub (Apr 20, 2018): +1

GiteaMirror commented

@bkcsoft commented on GitHub (Apr 28, 2018):

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

@bkcsoft commented on GitHub (Apr 28, 2018): 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 :)

GiteaMirror commented

@stevenroose commented on GitHub (Jun 12, 2018):

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.

@stevenroose commented on GitHub (Jun 12, 2018): 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.

GiteaMirror commented

@stale[bot] commented on GitHub (Jan 23, 2019):

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.

@stale[bot] commented on GitHub (Jan 23, 2019): 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.

GiteaMirror commented

@SamWhited commented on GitHub (Jan 23, 2019):

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.

@SamWhited commented on GitHub (Jan 23, 2019): 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.

GiteaMirror commented

@markusamshove commented on GitHub (Feb 6, 2019):

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

@markusamshove commented on GitHub (Feb 6, 2019): A RSS feed for `/notifications` would also be really handy and *might* solve some of the proposed features if you're watching a repository.

GiteaMirror commented

@nickho commented on GitHub (Feb 18, 2019):

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.

@nickho commented on GitHub (Feb 18, 2019): 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.

GiteaMirror commented

@immanuelfodor commented on GitHub (Feb 3, 2020):

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.

@immanuelfodor commented on GitHub (Feb 3, 2020): 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.

GiteaMirror commented

@SoulSeekkor commented on GitHub (Feb 3, 2020):

+1

@SoulSeekkor commented on GitHub (Feb 3, 2020): +1

GiteaMirror commented

@6543 commented on GitHub (Oct 19, 2020):

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?

@6543 commented on GitHub (Oct 19, 2020): 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?

GiteaMirror commented

@Pofilo commented on GitHub (Oct 19, 2020):

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.

@Pofilo commented on GitHub (Oct 19, 2020): 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.

GiteaMirror commented

@6543 commented on GitHub (Oct 19, 2020):

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

@6543 commented on GitHub (Oct 19, 2020): `A new RSS entry for each commit ?` - what about repo "Activeties" ?

GiteaMirror commented

@Zocker1999NET commented on GitHub (Oct 19, 2020):

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

@Zocker1999NET commented on GitHub (Oct 19, 2020): 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

GiteaMirror commented

@mpldr commented on GitHub (Nov 18, 2020):

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

@mpldr commented on GitHub (Nov 18, 2020): 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`

GiteaMirror commented

@bendem commented on GitHub (Nov 18, 2020):

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.

@bendem commented on GitHub (Nov 18, 2020): 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.

GiteaMirror commented

@mxmilkiib commented on GitHub (Dec 1, 2020):

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

@mxmilkiib commented on GitHub (Dec 1, 2020): It would be nice if Gitea could do what [GitHub](https://github.community/t/releases-atom-entry-has-atom-updated-but-not-atom-published/140644) and [GitLab](https://gitlab.com/gitlab-org/gitlab/-/issues/26800) don't yet by providing both date elements as well as separate release and tag feeds. Edit: I also found this [gitea-feed-workaround](https://webcache.googleusercontent.com/search?q=cache:OsQWWpEtgM8J:https://code.ka.com.kw/miscellaneous/gitea-feed-workaround/src/commit/9c652b9a2d54ea06bae4b0515dcd2ff42e2cc4fd/gitea-feed-workaround.sh%3Flang%3Dde-DE+&cd=1&hl=en&ct=clnk&gl=uk&client=firefox-b-d) (Google cache link as source is down).

GiteaMirror commented

https://github.com/go-gitea/gitea/pull/16002#issuecomment-916210155

@6543 commented on GitHub (Sep 9, 2021):

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

@6543 commented on GitHub (Sep 9, 2021): https://github.com/go-gitea/gitea/pull/16002#issuecomment-916210155 for those looking for this issue - please look at :point_up:

GiteaMirror commented

@6543 commented on GitHub (Oct 16, 2021):

update: user now supported, org next (wip)

@6543 commented on GitHub (Oct 16, 2021): update: user now supported, org next (wip)

GiteaMirror commented

@mxmilkiib commented on GitHub (Nov 28, 2021):

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

@mxmilkiib commented on GitHub (Nov 28, 2021): 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).

GiteaMirror commented