Is it possible to iterate over all the tags/releases from a GitHub Self-Hosted Runner?

[Rod-at-DOH]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

Actions Runner

Discussion Details

We're hoping that we can iterate over all the tags/releases to read all the semantic version numbers, so that we can calculate the next semantic version number during a GitHub Action, that is running on our server, in a GitHub self-hosted runner. Is that possible? If so, how can this be done?

[Radi410]

yes, it is absolutely possible. Since you are using a self-hosted runner, you actually have a slight advantage: you have direct access to the local git binary and the file system, which can be faster than hitting the GitHub API for every single tag.

Here are the two best ways to do this:

1. The "Git Native" Way (Recommended)
   This is the most reliable method because it doesn't depend on API rate limits. You can pull all tags directly from the repository's history.

Crucial Step: You must ensure your actions/checkout step fetches the entire history, not just the latest commit. By default, GitHub only fetches a "depth" of 1.

YAML
steps:
  - name: Checkout code
    uses: actions/checkout@v4
    with:
      fetch-depth: 0 # This fetches all tags and history

  - name: List and Calculate Version
    run: |
      # Get all tags, sorted by version number (highest first)
      tags=$(git tag --list 'v*' --sort=-v:refname)
      
      # Get the latest tag
      latest_tag=$(echo "$tags" | head -n 1)
      echo "The latest version is: $latest_tag"
      
      # Logic to calculate your next version (e.g., incrementing patch)
      # You can use a bash script or a Python utility here.

2. The "GitHub CLI" Way
   If you prefer not to fetch the entire git history (to save disk space on your runner), you can use the GitHub CLI (gh), which is usually pre-installed on most runners or easy to add.

Bash
This fetches the 10 most recent releases via API
gh release list --limit 10
3. Using a Pre-built Action
If you don't want to write the regex logic to parse SemVer yourself, there are "Marketplace" actions that do exactly this. A popular one is paulhatch/semantic-version.

YAML
- name: Get Next Version
  id: tagger
  uses: paulhatch/semantic-version@v5.4.0
  with:
    tag_prefix: "v"
    major_pattern: "(MAJOR)"
    minor_pattern: "(MINOR)"
    version_format: "${major}.${minor}.${patch}"

[Rod-at-DOH]

This is great news!! I've got a couple questions for you.

About the "Git Native" way

We've got a reasonably large Windows server for our self-hosted runner. I think it would be OK for us to use it. In the repo we're working on now, it is small, so I image even the git history shouldn't be too large. Of course, for other repos it will be larger. The question I have concerns how GitHub self-hosted runners' work. It is my understanding, and please correct me if I am wrong, that when a self-hosted runner is activated to run a GitHub workflow, that it launches a temporary VM (perhaps a container), into which the project is imported, the development environment is installed, the build and release occur, etc. Then when it is done, all that goes away. So, assuming there's enough disk space on the server, it should work fine and clean itself up when it's done.

Is that correct?

Concerning the SemVer approach

In my investigation as to possible ways of doing this, I came across SemVer. But I was left with the impression that I'd have to come up with a means of reading all the tags for the repo, then iterate through them applying SemVer to each to get the tag's name. Your YAML code gives me a hope that my approach isn't necessary. YEAH! And also, what encourages me is I can restrict the tag names we want to consider to just those matching a pattern of MAJOR.MINOR.PATCH, starting with the letter "v", which is a pattern we use. So, we needn't concern ourselves with other tags names that may have things like "pre-release" in it. Honestly, from my POV this looks like the best option. But since this isn't the recommended way of doing it, I'm wondering if there is some problem with SemVer? Is it slow? Is it sometimes unreliable? Why isn't it the recommended way?

[Rod-at-DOH]

@Radi410 what are the API rate limits you referred to? We have a GitHub Enterprise license, so I imagine ours is high.

[Radi410]

Self-hosted runners on Windows are actually persistent, not ephemeral, so they keep files in the _work folder unless you manually clean them or use the --ephemeral flag. The SemVer Action isn't unreliable or slow, it's actually more robust than custom scripts because it handles the regex and sorting for your "v" pattern automatically. It's often "not recommended" only by purists who prefer zero external dependencies, but for your case, it’s the most efficient choice in my opinion.

[Rod-at-DOH]

So, self-hosted runners on Windows persistent the files from a workflow run. Dang it. 😠 I wasn't aware of that. That means I'll have to go and find some way of cleaning that stuff up.

I'm glad to know that SemVer will work for us. I'm going to give this a try.

[dhruvTerminal]

for tag in $(git tag --sort=version:refname); do
  echo "Processing: $tag"
done

[mohul2005]

Yes, it’s possible. A self-hosted runner doesn’t store tags or releases itself—it just runs jobs—but you can fetch and iterate over them during a workflow.

For tags, you use Git (e.g., fetch all tags and loop through them).
For releases, you use the GitHub API or GitHub CLI.

So basically: the runner can access and iterate over tags/releases, but only by pulling them from the repository or GitHub, not from itself.