Auto-generate apk RTFace_Login/.github/workflows/build-workflow.yml should increment version number

[JackMostow]

https://github.com/RoboTutorLLC/RTFace_Login/blob/development/.github/workflows/build-workflow.yml ll. 31ff:
- name: Get app version name
id: get_version_name
run: echo "VERSION_NAME=$(./gradlew -q getVersionName --warning-mode=none)" >> $GITHUB_OUTPUT
# steps.get_version_name.outputs.VERSION_NAME

Just fetches version_name from gradlew

gradlew doesn't mention version, so presumably getVersionName is an Android method that magically fetches app version name

and need to call set_version_code to increment it

@gargVader - I know you only have time to advise, not to implement, but can you suggest who on the RoboTutor team is familiar with this type of witchcraft ;-_?

[gargVader]

The correct way to automatically increment version number is that everytime a pull request is merged to development branch, run a workflow that does the following:

• Bumps up the version number
• Makes a commit
• Creates a pull request
  Refer to this for help.

[JackMostow]

@gargVader - I appreciate your prompt and informative response, especially the pointer to this for bumping the version number. However, if it runs only when a PR is merged to development, why does it need to make a commit or create a pull request?

[gargVader]

Ideally we should only use APKs from development branch. Bumping up the version number is a code change. So, in order to put that into effect, a commit is required.

[JackMostow]

We need to test new apks before merging them into the development branch, so our travis script generated a new apk whenever anyone made a pull request, rather than wait till merging it. So should our script that uses GitHub actions.

Shouldn't a pull request trigger the bump, rather than wait till the merge into the development branch, so as to bump the version whenever a new apk gets generated? Or is it important to do as part of the merge, in order to keep the version number consistent among branches?

[gargVader]

Yes, it is to keep the version number consistent among branches.

Consider the following case.

• development is at 1.0.0.0.
• Two branches branch1 and branch-2.
• Both branches make their own changes and create a PR. In the same PR, we also bump up the version.
• So, now both branch-1 and branch-2 are on 1.0.0.1, but with different commits. This is a conflict.