GitLab Atom Feeds: Auto-Post Tags, Commits and Issues

Short answer: GitLab publishes Atom feeds for many project pages, including tags, commits, issues and user or group activity. Open the page you want to follow, copy the address behind its subscribe icon, add it as a source in an auto-poster and each new tag, commit or issue is announced on the channels you choose. Use feeds of public projects for public announcements, never put a private feed address in a public tool, and filter the noise so that your channel stays useful.

GitLab is used for source code, issue tracking and release management by open-source communities and by companies that host their own instance. People who follow a project often have no time to open its pages every day, and teams want to know when something relevant changes. Atom is a feed format, closely related to RSS, and GitLab offers it in many places. Because an auto-poster can read both Atom and RSS, a feed address is all it needs to turn project activity into posts. This guide explains which feeds exist, how to find their addresses, how to protect private data, how to avoid a flood of messages and which channels suit each type of update.

Which GitLab feeds exist

Many pages in GitLab have a subscribe or feed icon. The address behind it is an Atom feed. The most useful ones are:

• Tags. The tags page of a project, with the format parameter set to atom, lists new tags. Many projects create a tag for each release, so this is the closest equivalent of a release feed.
• Commits. The commits page of a branch can also be read as an Atom feed. It is busy, and it is more useful inside a team than on a public channel.
• Issues and merge requests. The lists of issues and merge requests have feed icons. They are useful for a team triage channel or for a public roadmap.
• Activity of a user or a group. A profile or group page can offer an activity feed, which lists recent events.

The exact paths can change between versions and between GitLab.com and a self-managed instance, so do not guess. Open the page, click the feed icon or copy the link behind it, and test the address in a browser or with curl, as explained in debugging an RSS feed with curl. A valid feed starts with an XML declaration and a feed element.

Who benefits from announcing GitLab activity

Several groups gain from turning project activity into posts:

• Open-source maintainers who want each new tag announced on Mastodon, Bluesky or a community chat without writing a separate message.
• Companies with public repositories who want customers and developers to hear about new versions of an SDK or a tool.
• Internal teams who want a message in a team chat when an important issue is opened or a tag is created.
• Community managers who follow several projects and publish a weekly stream for their members.

For projects hosted on GitHub, the same idea is described in auto-posting GitHub releases to social media and Discord. The principle is identical: find the feed, connect it and decide what deserves an announcement.

Setting up a GitLab feed

1. Open the page you want to follow, such as the tags page of a project.
2. Copy the feed address from the subscribe icon or add the Atom format parameter, then open it in a browser to confirm that it returns XML.
3. Add the address as a source in your auto-poster.
4. Connect the channels where your readers are.
5. Choose how each post is built from the title, the content or both.
6. Set a start date so that only new items are posted, and check the first posts on each channel.

Decide in advance whether old items should be posted. If you add a feed with years of history, an auto-poster might treat existing items as new. A start date prevents that.

Public and private projects

Public projects can be read by anyone, so their feeds need no secret. Private projects are different. Feeds of private content usually include a personal token in the address, which acts like a password: anyone who has the address can read the feed. Treat such an address as a secret. Do not paste it into public pages, tickets or chats, and do not use a private feed to publish to a public channel, because the titles and links may reveal confidential work. If you must follow a private project, send its announcements only to a private team chat, and rotate the token if the address is ever exposed. When in doubt, create a separate tag or issue label for public news and follow only that.

Keeping announcements useful

A feed item is written for people who work in the project, not for a general audience. A few habits make the posts clearer:

• Name the project. If the item title does not show the project name, send the feed to a channel where the project is obvious or add the name in the message format.
• Announce tags, not every commit. A public channel with every commit message is rarely read. Use the tags feed for public news and keep commits for developers.
• Write good tag messages. If your tags carry short release notes, the content of the feed item becomes a readable announcement.
• Link to the changelog. Point readers to a page that explains what changed and what to do about it.
• Use hashtags sparingly. Two or three relevant tags help discovery on Mastodon and Bluesky.

Filtering the noise

Some feeds are busy. A project with many contributors can produce dozens of items a day. Keyword filters help by including only items that contain certain words, such as a release prefix, or by excluding words such as wip, draft or test. PostRSS can include or exclude items by keywords found in the title and the description, so one source can be tuned for a specific purpose. You can also limit the number of posts per update and choose posting windows, so that a burst of activity does not fill a channel in minutes. For teams, a quiet daily window in a chat channel is more useful than a constant stream.

Choosing the right channels

Most projects do best with one public channel for tags and one team channel for issues. More ideas on connecting feeds to team tools are in RSS to team chat and in auto-posting to Slack and Microsoft Teams.

Self-managed GitLab instances

Companies that run their own GitLab server can use the same feeds, with the address of their own domain. Check three things. The server must be reachable from the internet if the auto-poster runs outside your network, otherwise the feed will not load. A web application firewall or single sign-on page in front of GitLab may block the fetch and return a login page instead of XML. If the server uses a private certificate, an external tool may refuse the connection. For internal-only instances, a team chat integration that runs inside the network is usually the better tool, and an external auto-poster is best reserved for public instances.

Atom or RSS: does it matter?

Atom and RSS are two XML formats for the same purpose: a list of items with titles, links, dates and summaries. GitLab uses Atom, and most auto-posters read both without any difference for you. The practical points are few. Atom items carry a stable identifier, which helps an auto-poster avoid sharing the same item twice. The summary may contain HTML, which the tool converts to plain text for networks that do not support markup. The date is the time of the update, so an edited item may look new in some feeds. If you want to compare the formats in detail, see JSON Feed vs RSS; the same reasoning applies to Atom.

A sample setup for a small open-source project

Imagine a library with a public GitLab project, a chat server for users and an account on a social network. The maintainers create a tag for each release and write two lines of release notes in the tag message. They add the tags feed as a source and connect it to the project account on Mastodon and to a releases channel in the user chat. They set a start date of today and exclude tags that contain rc or beta. The post shows the tag name, the first lines of the notes and the link to the tag page. For major versions, a maintainer writes a separate post with an example and a link to the migration guide. The setup takes about half an hour, and from then on every stable release is announced within minutes of the tag being pushed, with no extra step in the release checklist.

A sample setup for a product team

A company team keeps an internal project on a self-managed server. They follow the issues feed filtered by a label for incidents and send it to a private team channel, so that everyone sees new incidents without opening the tracker. A second source follows the tags feed and posts to a deployments channel. Nothing from the private project goes to a public network. The team reviews the filters every quarter, because labels and naming habits change, and they remove sources that nobody reads. This keeps the channels quiet enough to be useful.

Common mistakes to avoid

• Sharing a private feed address. A token in the address is a password. Keep it out of public places.
• Posting every commit publicly. It creates noise and reveals half-finished work.
• Posting old items on the first run. Set a start date.
• No project name in the message. Readers need to know which project changed.
• Ignoring failures. If the feed starts to return an error, check the address and the permissions; see RSS feed HTTP status codes explained.
• Using automation instead of communication. A breaking change deserves a personal explanation, not only an automatic post.

How PostRSS helps with GitLab announcements

PostRSS has been publishing RSS and Atom feeds to social networks since 2014. Add a GitLab Atom feed address as a source, connect your accounts and choose how each post is built from the title, the description or the page title. PostRSS checks the feed as often as every minute and shares each new item, with its link, to the channels you choose among 66 supported networks, messengers, team chats and blogs, including Mastodon, Bluesky, Matrix, Discord, Telegram and LinkedIn. Keyword filters, a start date, a limit on posts per update and posting windows keep the stream under control, and the REST API and webhooks connect PostRSS to your own systems. See the PostRSS features page and the plan limits on the pricing page. More developer guides are under the Technical Guide tag.

Saistīta lasāmviela

• Auto-post GitHub releases to social media and Discord
• Docusaurus RSS feed for a blog and changelog
• Status page RSS feeds for incident updates

The bottom line

GitLab already offers Atom feeds for tags, commits, issues and activity, and an auto-poster only has to listen. Find the feed address behind the subscribe icon, protect private feeds like passwords, choose a start date, name the project in each message and filter out the noise. Announce tags publicly, keep commits and issues in team channels, and add a personal post for the releases that deserve an explanation.

FAQ

Does GitLab provide RSS or Atom feeds?

Yes. Many pages, such as tags, commits, issues and activity, offer an Atom feed. Open the page and use the subscribe icon, or copy the feed link, and test the address in a browser.

Can I announce only new releases?

Often yes. Many projects create a tag for each release, so the tags feed works as a release feed. Use keyword filters if you want to include only certain tag names.

Is it safe to use a private project feed?

Only for private channels. A private feed address contains a token that works like a password. Never share it, and do not publish private titles on public networks.

Will old tags be posted when I add the feed?

That depends on the settings. Choose a start date so that only new items are shared, and check the first posts after you connect the feed.

Can I use a GitLab feed with PostRSS?

Yes. Paste the Atom feed address as a source in PostRSS, connect your accounts and each new item is posted automatically. Make sure the address opens without a login first.

{“@context”: “https://schema.org”, “@type”: “FAQPage”, “mainEntity”: [{“@type”: “Question”, “name”: “Does GitLab provide RSS or Atom feeds?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “Yes. Many pages, such as tags, commits, issues and activity, offer an Atom feed. Open the page and use the subscribe icon, or copy the feed link, and test the address in a browser.”}}, {“@type”: “Question”, “name”: “Can I announce only new releases?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “Often yes. Many projects create a tag for each release, so the tags feed works as a release feed. Use keyword filters if you want to include only certain tag names.”}}, {“@type”: “Question”, “name”: “Is it safe to use a private project feed?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “Only for private channels. A private feed address contains a token that works like a password. Never share it, and do not publish private titles on public networks.”}}, {“@type”: “Question”, “name”: “Will old tags be posted when I add the feed?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “That depends on the settings. Choose a start date so that only new items are shared, and check the first posts after you connect the feed.”}}, {“@type”: “Question”, “name”: “Can I use a GitLab feed with PostRSS?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “Yes. Paste the Atom feed address as a source in PostRSS, connect your accounts and each new item is posted automatically. Make sure the address opens without a login first.”}}]}