Feature Request: Auto-incrementing counter functionality

[deadlydog]

Select Topic Area

Product Feedback

Body

Azure DevOps Pipelines offers a counter expression that I would love to see similarly implemented in GitHub Actions. It allows you to have an auto-incrementing integer in your pipelines that does not rely on git tags or writing the number somewhere back to the git repository. This is extremely useful for a variety of scenarios, including versioning (both semantic and non-semantic). The semantic versioning actions available on the marketplace today rely on cluttering up the git tags.

I know there are the context variables github.run_id, github.run_number, and github.run_attempt which are useful in their own right, but do not provide quite the same functionality as the counter expression. The counter allows you to provide a prefix and a seed. The counter starts at the seed value and increments on every run. If the prefix changes, then the counter resets back to the seed value.

For example, if we use the following in our workflow yaml file:

• prefix: 1.0
• seed: 100
• version = prefix + . + counter(prefix, seed)

Then we would see these results:

• First run version is 1.0.100
• Next run version is 1.0.101
• Next run version is 1.0.102
• Say we then change the prefix in our workflow yaml to be 1.1
• Next run version is 1.1.100
• Next run version is 1.1.101
• Say we then change the prefix in our workflow yaml to be 2.0
• Next run version is 2.0.100
• Next run version is 2.0.101
• Next run version is 2.0.102
• and so on....

Please consider adding functionality similar to the Azure Pipelines counter expression to GitHub Actions to enable flows that are not currently possible, or are very cumbersome to implement otherwise.

[abhisheksiddhu]

This is one of the major roadblocks stopping me to shift from Azure DevOps to GitHub

[geoffblandrbs]

This is also a major block to us migrating from SVN to Git. We have to use the SVN release number to check that this version of our code is allowed to be used with older releases being blocked. The app version number needs to be both sequential and to uniquely identify the check-in so it can be used to retrieve the source.

[dmwh-mmonacelli]

Is this functionality still missing? Have any of you found a way to accomplish this in Github Actions?

[latobibor]

@deadlydog
https://stackoverflow.com/questions/54310050/how-to-version-build-artifacts-using-github-actions
It seems you can use a couple of counters if it is "close enough" to an incrementing version number you want.

[deadlydog]

Thanks @latobibor , I had found that Stack Overflow answer before posting my feature request, and did mention the counters it covers in my original post. One of the primary use cases that I want covered is to be able to implement semantic versioning without tags, which you cannot do with the counters available today since you cannot reset them to zero or set the seed value they should start from.

[raphaZahnd]

I also haven't found a solution to implement automatic versioning. I tried with caches but the problem is that each branch creates their own cache so you can't save the last build version as reference to calculate the next for the whole repo. The versions are therefore not guaranteed to be unique. This feature request would make it much simpler or even just possible to have automatic semantic versioning.

[KinNeko-De]

variables:
  - name: majorMinorVersion
    value: 1.0
  - name: semanticVersion
    # semanticVersion counter is automatically incremented by one with each pipeline execution.
    # The second parameter is a seed value that the counter resets to whenever the referenced majorMinorVersion is changed.
    value: $[counter(variables['majorMinorVersion'], 0)]

name: $(majorMinorVersion).$(semanticVersion)

In my Azure Pipelines, I use a version number and a counter within the YAML. I only manually increment the version number for new features or breaking changes, following semantic versioning rules.

On GitHub, I have to use a workaround: I manually update the full version number with every commit. To remind me, I created a custom "Version upgraded?" action that intentionally fails the pipeline. This action uses Git tags as a reference. The biggest issue is that this process breaks with every Dependabot pull request, forcing me to manually increase the version number each time.

A built-in counter, like the one in Azure, would be much more convenient.