Generate new version even no new commits found

[ivan-sre]

Is it possible to "force" the version generation in case "No changes detected for this commit"?

Thanks,
Ivan

[PaulHatch]

Hey @ivan-sre, I am not quite sure what you are asking. The only time changes are actually checked for is when a change_path is specified. This is intended for mono-repo scenarios where you would want to avoid building/versioning a service that had not changed.

[ivan-sre]

Hello @PaulHatch!
When I try to run my workflow twice on the same commit - it doesn't generate new version.
Let's say we have tag v1.0.0.
Now I create a new commit - push and run my workflow, it generates new version v1.0.1 (the tag v1.0.1 is created).
If I try to run the workflow again, it print "No changes detected for this commit" and "Version is 1.0.1"
It seems to be "1.0.2", no?

[PaulHatch]

No, this action looks for the previous version and increases that by a single version increment. You can enable bump each commit where each new commit will increment the version as if it were tagged, but in any case with any configuration, rerunning the action on the same commit on the same repo should always produce the same result.

There is no state save between runs, the Git repo itself is the source of truth. I am not sure why you are getting this message, that is logged when the value of changed is false, but that is only checked if a change path is specified.

[ivan-sre]

Hi @PaulHatch !
First of all, I would like to say "thank you" for this great project!

I guess I know why I got the message "No changes detected for this commit" - I was using version "5.0.2" instead of "5.0.3", sorry for that.

The approach "same commit" => "same result" is good for most of cases, but not always.
IMHO there is no "right" or "wrong" approach, I believe in formula "best practices + common sense".
For my specific case it will be nice to have possibility of creating new release on the same commit for some possible reasons:

• something changed in external world (i.e. my Dockerfile installs the latest debian package - I may need to have a new release with new security fixes only)
• some external service didn't do its job properly (as part of my workflow)
• some secret was changed and new version of the secret causes to different result
• ...
  The most of these reasons are because of our build usually depends on something outside of the repo, it happens.

So, if you decide to add this "small" feature - it will be really cool.

Anyway, thank you!

Regards,
Ivan

[PaulHatch]

Hey @ivan-sre, glad you find it useful. So adding a feature like this definitely goes against the grain of how the action currently works, and from the perspective of your user they would see gaps whenever you did this, e.g. the release list could be 2.1.7, 2.1.8, 2.1.11, which IMO is not a good user experience. Avoiding this situation was the primary motivation for creating this action.

HOWEVER, there's nothing at all stopping you from using other information to create your semver label, for example 2.1.8-pre5-deb11.6 indicating the source was changed 5 times since 2.1.7 was released and it has been packaged using Debian 11.6. Some people use a hash as the label. This action is only providing certain information for your use. There is a version format input and a formatted version output that if I could go back in time and start over I thing I would have not even provided because it comes across as being more prescriptive than intended and blurs the scope of this action a bit--you don't need to use this and can format your version however you need to. (I myself tend not to use it)

Alternately if you really were set on incrementing the version, you can just tag it, the next build will pick up the latest (highest) tag. Since there is nothing to calculate, I suppose you'd always increment the patch value, and on the next run the action will pick it up and start from there.

[nnshet]

Hi @PaulHatch I also need to have tags to be added when no new commit is found. I tried the alternate approach which you mentioned here where I increment the tag and update it. But when the build is run next time still the old tag is picked up not the highest.
Example commit1 has tag v1.0.1. Now I created another tag v1.0.2 and added to commit1. When the action runs, it still picks up v1.0.1. Is this expected?
However if I add new commit, when the action is run it will pick up v1.0.2 and return v1.0.3 which is expected.
Without adding any commit it still returns v1.0.1? Am I doing something wrong here? Also I added tag to a commit manually from github ui just for testing purpose.

[PaulHatch]

It should be picking up the highest version. For example this test passes:

test('Highest tag is chosen when multiple tags are present', async () => {
    const repo = createTestRepo();

    repo.makeCommit('Initial Commit');
    repo.exec('git tag v2.0.0');
    repo.exec('git tag v1.0.0');
    repo.exec('git tag v1.5.0');    
    var result = await repo.runAction();
    expect(result.formattedVersion).toBe('2.0.0+0');

    repo.exec('git tag v3.0.0');
    repo.exec('git tag v2.1.0');
    result = await repo.runAction();
    expect(result.formattedVersion).toBe('3.0.0+0');

    repo.makeCommit('Additional Commit');
    result = await repo.runAction();
    expect(result.formattedVersion).toBe('3.0.1+0');

}, timeout);

Could you provide a test case to demonstrate your use case? You can find instructions on creating a test case in the contributing guide.