Skip to content

Added: test case for https://github.com/PaulHatch/semantic-version/is…#180

Draft
mattbryce93 wants to merge 1 commit intoPaulHatch:masterfrom
mattbryce93:hotfix/version-from-branch-mismatch
Draft

Added: test case for https://github.com/PaulHatch/semantic-version/is…#180
mattbryce93 wants to merge 1 commit intoPaulHatch:masterfrom
mattbryce93:hotfix/version-from-branch-mismatch

Conversation

@mattbryce93
Copy link

…sues/179

Have some minor spelling mistakes also whilst checking the contributing docs.

These test cases demonstrate the issue described in #179

The test cases demonstrate the conflict of expectation when using the verion_from_branch functionality. If someone mistakenly has a matching sting in their commits, the reult from the following tests are:

● Versioning from branch always ignores major commit pattern

    expect(received).toBe(expected) // Object.is equality

    Expected: "3.2.1+1"
    Received: "4.0.0+0"

      1158 |     const result = await repo.runAction();
      1159 |
    > 1160 |     expect(result.formattedVersion).toBe('3.2.1+1');
           |                                     ^
      1161 |
      1162 | }, timeout);
      1163 |

      at src/main.test.ts:1160:37
      at fulfilled (src/main.test.ts:28:58)

  ● Versioning from branch always ignores minor commit pattern

    expect(received).toBe(expected) // Object.is equality

    Expected: "3.2.1+1"
    Received: "3.3.0+0"

      1174 |     const result = await repo.runAction();
      1175 |
    > 1176 |     expect(result.formattedVersion).toBe('3.2.1+1');
           |                                     ^
      1177 |
      1178 | }, timeout);

      at src/main.test.ts:1176:37
      at fulfilled (src/main.test.ts:28:58)

I did try and figure out where this would be fixed in the source code of the action, admittedly I got a bit lost in the DefaultLastReleaseResolver.ResolveAsync function. I'm also not sure @PaulHatch what you would like to do with this, or if it is intentional. So I'll await and see what you think, admittedly you may be better at producing a patch for this, seeing as I did get a bit lost in figuring out what the fix should be.

@mattbryce93
Copy link
Author

Looking into the code, we get the bumps occuring when this classification variable is generated:

const classification = await versionClassifier.ClassifyAsync(lastRelease, commitSet);

tagFormatter in this context is the BranchVersioningTagFormatter class. I'm wondering if it would be worth adding a boolean value as a variable into the versionClassifier.ClassifyAsync function to give it context of being a branch based version calculation and always returning a Patch in that situation?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant