[GH Actions] Update semantic versioning for Expensify.cash

Upwork posting: https://www.upwork.com/jobs/~011cb60c9e032b2c3b

If you haven’t already, check out our contributing guidelines for onboarding!

---

Problem

We use the following semver (semantic versioning) schema for Expensify.cash: MAJOR.MINOR.PATCH-BUILD. Right now, the bumpVersion action only ever increments the BUILD version, but we need to be able to increment other segments of the semver version, too.

Why is this important?

This is a requirement in order to deploy Expensify.cash mobile to production.

Solution

We need the following updates made to the existing bumpVersion action:

1. It should take a SEMVER_LEVEL input which must be one of: [MAJOR, MINOR, PATCH, BUILD]
2. Based on the SEMVER_LEVEL parameter, it must update the correct portion of the semver version. So if the current version were 1.0.1-444 and I execute the bumpVersion action w/ a SEMVER_LEVEL of BUILD, the new version should be 1.0.1-445.
3. Whenever you update a higher SEMVER_LEVEL, the lower levels should be reset to 0. For example, if the the current version were 1.0.2-444 and I execute the bumpVersion action w/ a SEMVER_LEVEL of MINOR, then the new version should be 1.1.0.
4. A BUILD level of 0 should not be included in the semantic version. So if the the current version were 1.0.1-444 and I execute the bumpVersion action w/ a SEMVER_LEVEL of PATCH, then the new version should be 1.0.2, not 1.0.2-0.
5. We also need this action to output the new version string to the workflow that executes it.
6. The maximum number for each SEMVER_LEVEL should be 999, and if the maximum is reached then it should automatically bump the next level up. For example, if the current version is 1.0.999 and I execute this action w/ a SEMVER_LEVEL of PATCH, then this action should update the version to 1.1.0, not 1.0.1000.
7. The existing functionality, which retries the npm version command in the event of a race condition/version conflict must be maintained.
8. Automated tests should be written to cover all the functionality of this action.

To be considered complete

• Verify that all 8 of the above are satisfied
• Document testing done for this action in a separate repo before we will merge a PR and QA it in Expensify.cash
• Provide a set of automated tests
• You must test that all build levels are updated as expected.
• Verify that the action still properly handles the npm version race condition that can occur if two or more PRs are merged in quick succession. You can test this by:
  1. Manually create a git tag in your repo for the highest existing version +1
  2. Execute this action, and if it bumps the version to the level of the tag you created in the previous step +1, then it was a success.
• Verify that the version generated by this action is successfully output to the workflow that executed it by echoing the version in the workflow.

[roryabraham]

Thanks @parasharrajat

[parasharrajat]

This issue is already resolved and thus should be closed.