Patch version taking the number of commits

[jeba-schulz-epam]

Hi @PaulHatch

I have gone through the entire documentation, as per your information If it isn't a major or minor release, it will be a "patch" type by default.

But when i run with version_format: "${major}.${minor}.${patch}" patch is still taking the total number of commits even in the first run.

I don't see patch is being incremented normally like major and minor. can you please help here

also can you please add patch_pattern : "fix:" something like this so that patch can be incremented with the keyword similar to minor and major versions?

Thanks

[PaulHatch]

Perhaps you have bump_each_commit set to true?

This test indicates the expected behavior, and runs correctly for me:

test('Patch increments only once', async () => {
    const repo = createTestRepo({ tagPrefix: '', versionFormat:  "${major}.${minor}.${patch}" });

    repo.makeCommit('Initial Commit');
    repo.exec('git tag 0.0.1');
    const firstResult = await repo.runAction();
    repo.makeCommit('Second Commit');
    const secondResult = await repo.runAction();
    repo.makeCommit('Third Commit');
    const thirdResult = await repo.runAction();
    repo.makeCommit('fourth Commit');
    const fourthResult = await repo.runAction();
    
    
    expect(firstResult.formattedVersion).toBe('0.0.1');
    expect(secondResult.formattedVersion).toBe('0.0.2');
    expect(thirdResult.formattedVersion).toBe('0.0.2');
    expect(fourthResult.formattedVersion).toBe('0.0.2');
    
}, 15000);

Contrast that behavior with bump each commit enabled, which does show the behavior you describe.

test('Patch increments each time when bump each commit is set', async () => {
    const repo = createTestRepo({ tagPrefix: '', versionFormat:  "${major}.${minor}.${patch}", bumpEachCommit: true });

    repo.makeCommit('Initial Commit');
    repo.exec('git tag 0.0.1');
    const firstResult = await repo.runAction();
    repo.makeCommit('Second Commit');
    const secondResult = await repo.runAction();
    repo.makeCommit('Third Commit');
    const thirdResult = await repo.runAction();
    repo.makeCommit('fourth Commit');
    const fourthResult = await repo.runAction();
    
    
    expect(firstResult.formattedVersion).toBe('0.0.1');
    expect(secondResult.formattedVersion).toBe('0.0.2');
    expect(thirdResult.formattedVersion).toBe('0.0.3');
    expect(fourthResult.formattedVersion).toBe('0.0.4');
    
}, 15000);

There has been some discussion already here about supporting a patch_pattern type parameter specifically for when bump_each_commit is used but you don't want to increment unless a pattern is found. Maybe this can go into v5.1.0.

[jeba-schulz-epam]

Hi @PaulHatch

thanks for the reply..

in my case bump_each_commit: false

my only error occurring case is this line

Error: Validation Failed: {"resource":"Release","code":"already_exists","field":"tag_name"}

i just removed the tag_prefix : v. Is it incorrect to remove that?. Please advise

[PaulHatch]

The tag_prefix is v by default, so removing that will have no effect. This input is used when looking up the tag of the previous version. With v the action will be looking for tags like v1.0.0, while if empty it will look for tags like 1.0.0.

I am not sure where this error is coming from, there is no field in this action called tag_name, but it sounds like you are confusing this with the tag and release action, which has an input with this name.

If you are tagging every commit, that is probably the source of the behavior you are seeing above. As described in the introduction section of the readme, this action is intended primarily for projects where the decision to release a given commit is made after the build has finished, projects that have some kind of gated release process that cannot be determined automatically during a build (for example QA, UAT, or any kind of approval or sign-off) which is typical in professional environments. If you are building a small project that is released on every commit, you can use the bump each commit rather than automatically tagging each commit.

As I mentioned above there is an open ticket right now to allow this bump each commit behavior to only increment when matching a commit message.

[PaulHatch]

Note that in the case of bump_each_commit: true as of v5.0.2 you do not need to tag unless you want to override the version.

[jeba-schulz-epam]

Hi @PaulHatch Good day..!

I have a scenario here in my workflow. We usually run cronjobs every day during off-business hours. We need to create a version for that as well. As you know cronjob is configured as schedule and no commits will be made. Any possible way to make this action run and generate a new version for the cronjob schedule as well?. Please advice. Thanks

[PaulHatch]

There are two ways you can bump the version (meaning increase the major, minor, or patch version):

• Create a tag. The version of subsequent commits will be increased by one
• Enabled bump_each_commit, this will cause the action to behave as if each commit had been tagged. Since you don't have a commit, this will not work for you

Note that once a commit has been tagged, running the action on that commit will return the tagged value. In the latest version (currently latest, as it has not been included in a release yet), the is_tagged value will indicate that this is the case, thanks to a contribution from @Kantis. You could use this to optionally increment the tag in your cron job.

As an aside, versioning each build like this sounds like there's some mixing of concepts going on here. Semantic versioning is intended to convey some specific information about a release outlined in the spec. In this situation I'd probably recommend using a label with the date in your case, and not incrementing the version, e.g. 1.2.3-230321.