Better integration with `commit_version_bump`

[dusek]

Currently someone who uses increment_build_number together with commit_version_bump has a little rough time when using stamp_changelog. E.g. consider the following code:

    increment_build_number
    stamp_changelog(section_identifier: "#{get_version_number} (#{get_build_number})")
    commit_version_bump

commit_version_bump will complain that:

[!] Found unexpected uncommited changes in the working directory. Expected these files to have 
changed: 
appname.xcodeproj/project.pbxproj
appname/Info.plist
appnameTests/Info.plist
appnameUITests/Info.plist.
But found these actual changes: 
CHANGELOG.md
appname.xcodeproj/project.pbxproj
appname/Info.plist
appnameTests/Info.plist
appnameUITests/Info.plist.
Make sure you have cleaned up the build artifacts and 
are only left with the changed version files at this stage in your lane, and don't touch the 
working directory while your lane is running. You can also use the :force option to bypass this 
check, and always commit a version bump regardless of the state of the working directory.

If we git_add(path: 'CHANGELOG.md') before committing version bump, the same error will happen.

If we add force: true parameter to the commit_verison_bump on its own, it avoids the error, but leaves the changes to CHANGELOG.md caused by stamping as uncommitted changes.

Only combination of both is a working workaround:

    increment_build_number
    stamp_changelog(section_identifier: "#{get_version_number} (#{get_build_number})")
    git_add(path: 'CHANGELOG.md')
    commit_version_bump(force: true)

I think a better solution would be to change fastlane itself to introduce e.g. a VERSION_BUMP_PATHS lane context value. Actions like fastlane's own increment_build_number and increment_version_number, or this plugin's stamp_changelog, could then register files with changes related to bumping version. The commit_version_bump action would then use this shared lane context value, instead of its hardcoded list of files, to determine which files need committing for the version bump.

I will file an issue with fastlane proposing this enhancement which fastlane-plugin-changelog could then take advantage of.

[pajapro]

Hi @dusek thanks for feedback. I encountered this issue as well, here is how I go around it:

increment_build_number
# build, test etc.
commit_version_bump
stamp_changelog(section_identifier: "Build #{build_number}")
git_commit(path: "./CHANGELOG.md", message: "Stamp released build #{build_number} in CHANGELOG")
push_to_git_remote

I like this workaround better, because it's sort of synchronised approach:

1. increment build then commit,
2. stamp changelog then commit,
3. lastly push everything to remote.

I think a better solution would be to change fastlane itself to introduce e.g. a VERSION_BUMP_PATHS lane context value.

I don't think commit_version_bump action should be committing anything else than changes caused by increment_build_number/increment_version_number

I will file an issue with fastlane proposing this enhancement which fastlane-plugin-changelog could then take advantage of.

Perhaps the best approach would be to introduce an optional parameter to stamp_changelog, something like commit_stamp_changes, which would commit whatever changes happened to (and only to) CHANGELOG.md - what do you think?

[dusek]

Thanks @pajapro for the response.

I still like my version better:

• it creates less "maintenance" commits (i.e. those without changes to the app code itself) and therefore less "noise" in the commit log (I prefer to see real changes, i.e bug fixes and feature implementations, in the commit log, not "maintenance" changes). This is probably more relevant to us as we produce a new testflight build (and therefore version bump commit) after each merged pull request.
• it also makes IMHO more sense - when I think about it, defining a new build/version number in Info.plist key and specifying the same new build version/number in CHANGELOG.md is for me different forms of a single thing - bumping the version (stamp_changelog really does nothing more). So it makes more sense to me that they are all handled in a single "version bump" commit.

But I am still open for other ways to look at this 😄 . Please let me know what you think.

[pajapro]

You have a really good points @dusek especially the one about the unnecessary noise in git log. What you wrote before:

I think a better solution would be to change fastlane itself to introduce e.g. a VERSION_BUMP_PATHS lane context value. Actions like fastlane's own increment_build_number and increment_version_number, or this plugin's stamp_changelog, could then register files with changes related to bumping version. The commit_version_bump action would then use this shared lane context value, instead of its hardcoded list of files, to determine which files need committing for the version bump.

would solve that problem. Did you file an issue on Fastlane main repo to discuss this possibility?

Personally, I am quite happy with:

git_commit(path: "./CHANGELOG.md", message: "Stamp released build #{build_number} in CHANGELOG")

despite the additional commit, because it provides me with fine grained control of changes to my source code.

[dusek]

Did you file an issue on Fastlane main repo to discuss this possibility?

Not yet, as I wanted to know what you think before I file one, and also did not have time yet to do it. Hopefully I will file it over the weekend, I will make sure I link there to this issue, so that you are aware and can participate in the discussion.

[pajapro]

Perfect, cheers @dusek

[dusek]

@pajapro Sorry for the delay, but I could not get to it earlier (and you will see that the result is not exactly short).

I finally filed the relevant issue with fastlane:

• fastlane#6071: RFC: Introduce VERSION_BUMP_PATHS to generalize commit_version_bump.

Please of course feel free to express any comments there you might have about it.

[pajapro]

Thank for creating the issue @dusek