The step was not compatible with the new build format introduced with Xcode 13 and this PR adds that ability. I have also converted the step to use Go. In some sense the step become simpler and also more complex at the same time.
It is simpler from the user's perspective because they do not need to configure the step because it will just work with the default settings. During my investigation I discovered that the $BITRISE_PROJECT_PATH and $BITRISE_SCHEME variables are enough to update the build numbers. But I also made the target and configuration settings accessible for total configuration.
But the steps code became more complicated because it has to support the old and new configuration at the same time.
Two things to note. The step does not use that unified CI yet. This will come in a second PR. And I have added more e2e tests than unit test to test the logic. This is on purpose because I had to mock too many things so I decided to create very simple sample apps and include them in the repo. Then I build these apps and check the version numbers in the final product. Usually we include the sample apps in separate repos but these are so simple and purpose made for a single use case so I decided to leave them here.
Flow
The step first reads the GENERATE_INFOPLIST_FILE from the project settings. This will tell if the plist file is generated from the project settings or is a static file. This value decides what is the next step for the step.
If it is generated then it will update CURRENT_PROJECT_VERSION and MARKETING_VERSION values in the project. If the user did not provide a target and configuration then it will use the scheme's default target and configuration. Otherwise it will find the target and configuration the user entered. Once these values are updated then it saves the project file.
If the build numbers are located in the static plist file then the step will read the INFOPLIST_FILE value from the project. This is a path pointing to the static plist file so we do not need to ask this as an input from the user. After that it will update the CFBundleVersion and CFBundleShortVersionString values and save the file.
Checklist
step.ymlandREADME.mdis updated with the changes (if needed)Version
Requires a MAJOR version update
Context
The step was not compatible with the new build format introduced with Xcode 13 and this PR adds that ability. I have also converted the step to use Go. In some sense the step become simpler and also more complex at the same time.
It is simpler from the user's perspective because they do not need to configure the step because it will just work with the default settings. During my investigation I discovered that the
$BITRISE_PROJECT_PATHand$BITRISE_SCHEMEvariables are enough to update the build numbers. But I also made the target and configuration settings accessible for total configuration. But the steps code became more complicated because it has to support the old and new configuration at the same time.Two things to note. The step does not use that unified CI yet. This will come in a second PR. And I have added more e2e tests than unit test to test the logic. This is on purpose because I had to mock too many things so I decided to create very simple sample apps and include them in the repo. Then I build these apps and check the version numbers in the final product. Usually we include the sample apps in separate repos but these are so simple and purpose made for a single use case so I decided to leave them here.
Flow
The step first reads the
GENERATE_INFOPLIST_FILEfrom the project settings. This will tell if the plist file is generated from the project settings or is a static file. This value decides what is the next step for the step.If it is generated then it will update
CURRENT_PROJECT_VERSIONandMARKETING_VERSIONvalues in the project. If the user did not provide a target and configuration then it will use the scheme's default target and configuration. Otherwise it will find the target and configuration the user entered. Once these values are updated then it saves the project file.If the build numbers are located in the static plist file then the step will read the
INFOPLIST_FILEvalue from the project. This is a path pointing to the static plist file so we do not need to ask this as an input from the user. After that it will update theCFBundleVersionandCFBundleShortVersionStringvalues and save the file.