Additional options for command-line switch /overrideconfig.

[nenadvicentic]

All 'Gitversion.yml` options with simple property type (string, enum, int, bool) are now supported - 21 in total.

Description

As discussed in issue #2485 I've added support for all writeable properties from GitVersion.Model.Configuration.Config class (effectively Gitversion.yml) which have simple type (string, Enum, int, bool and their nullable counterparts).

Implementation uses Reflection to parse which properties fit criteria and uses "aliases" for property names provided by YamlMemberAttribute's Alias value.

Following /overrideconfig options are supported:

1. assembly-file-versioning-format
2. assembly-file-versioning-scheme
3. assembly-informational-format
4. assembly-versioning-format
5. assembly-versioning-scheme
6. build-metadata-padding
7. commit-date-format
8. commit-message-incrementing
9. commits-since-version-source-padding
10. continuous-delivery-fallback-tag
11. increment
12. legacy-semver-padding
13. major-version-bump-message
14. minor-version-bump-message
15. mode
16. next-version
17. no-bump-message
18. patch-version-bump-message
19. tag-prefix
20. tag-pre-release-weight
21. update-build-number

Related Issue

Support 'assembly-versioning-format' option as a part of '/overrideconfig' command line parameter #2485

Motivation and Context

In CI environment (GitLab, TeamCity), it makes sense that some of the customizations to the gitversion configuration can be overridden via command line. That allows for applying global changes (for example different assembly-versioning style) on company level, via shared CI build script template, instead of committing same configuration option to every single repository separately in Gitversion.yml files.

Since tag-prefix option has already been supported, I requested assembly-versioning-format, but instead agreed with @asbjornu that it is better make /overrideconfig option-parity with Gitversion.yml - to the extent that it is possible/reasonable , due to differences in (de)serialization fidelity between yml files and command-line arguments.

How Has This Been Tested?

Code is unit-tested for all currently available /overrideconfig options, common errors (wrong key, wrong value, format errors) and setting of multiple options at once.
In addition, I manually tested in windows console as well for couple of common options.

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

[nenadvicentic]

@arturcic, @asbjornu Guys, do you have any estimation when can review for this feature be done?

[asbjornu]

Excellent stuff!

[asbjornu]

I think this looks good now, thanks for adjusting the argument format. Rebase against main, resolve the conflicts and this should be good to go! 👏🏼

[nenadvicentic]

I think this looks good now, thanks for adjusting the argument format. Rebase against main, resolve the conflicts and this should be good to go! 👏🏼

I re-based the branch. It should be fine now. The unstable unit-tests (the once that failed now) seem to be something I've picked up during rebase from the main branch, unrelated to the code changes in this pull request.

[mergify]

Thank you @nenadvicentic for your contribution!