Hive
CURRENT_PROJECT_VERSION to CFBundleVersionGitHub issue · Open
I’m migrating an old project to Tuist.
I found that the new project wasn’t fully compatible to old fastlanes where we invoked fastlane run increment_build_number after I assigned the Info.plist to the project.
increment_build_number looked for CFBundleVersion in every Info.plist and also CURRENT_PROJECT_VERSION in the Xcode project to substitute the new build number.
This lane did update CFBundleVersion in my Info.plist file, but it failed on the generated Tuist project because of the empty CURRENT_PROJECT_VERSION:
There does not seem to be a CURRENT_PROJECT_VERSION key set for this project. Add this key to your target's expert build settings.
This was obviously because I didn’t set SettingsDictionary().currentProjectVersion(...) explicitly to Project.swift. However I already had one source of truth of the build number in the Info.plist file, I wonder if I could avoid adding the project version of the same value to Project.swift?
It would be nice if the generated project could have CURRENT_PROJECT_VERSION the same value as CFBundleVersion by default, for some advantages:
agvtool - which is invoked by Fastlane - where CFBundleVersion and CURRENT_PROJECT_VERSION are assumed as the same value.fastlane run increment_build_number works - it updates the values in the Xcode project and Info.plist, where the Xcode project won’t get in the version control, but the Info.plist will. We don’t need to write a new method to update both Info.plist and the Project.swift to increment the build number.Disadvantages though, could be
Wonder if this proposal sounds good, or it doesn’t actually make much sense to people?
14.4.1
4.15.0
15.1
P
@peteranny, thanks for bringing this up. I’m inclined to agree that’s a sensible default; however, it might be perceived as a breaking change for most projects, and therefore I’m a bit hesitant to do it shortly. We can keep it as something to re-consider when we plan to do a major project release. What do you think?
P
@peteranny, thanks for bringing this up. I’m inclined to agree that’s a sensible default; however, it might be perceived as a breaking change for most projects, and therefore I’m a bit hesitant to do it shortly. We can keep it as something to re-consider when we plan to do a major project release. What do you think?
Sure, glad to hear the echo. For my case I’ll go for reading Info.plist and inputting the bundle number to Project.swift via environment variable - thus still keeping the single source of truth being Info.plist. Will look forward to the next major update.
FS
P
@peteranny could you please share how you did it? I also have this issue and I wanted to access the Info.plist file to get the bundle number. Thank you
Sure, here is my custom fastlane:
lane :tuistgen do |options|
root = ".."
ENV["TUIST_PROJECT_VERSION"] = project_version(root)
sh("mise exec -- tuist generate -p #{root}")
end
def project_version(root)
path = Dir[root + "**/Info.plist"].first
path = Pathname.new(path).realpath
key = "CFBundleVersion"
value = Helper.backticks("defaults read #{path} #{key}").strip
return value
end
and Project.swift be like:
let project = Project(
// ...
settings: .settings(
base: SettingsDictionary().currentProjectVersion(),
)
)
extension SettingsDictionary {
func currentProjectVersion() -> SettingsDictionary {
guard case .string(let projectVersion) = Environment.projectVersion else {
fatalError("Must run the generation with TUIST_PROJECT_VERSION=X")
}
return currentProjectVersion(projectVersion)
}
}
You can find the documentation for the usage of environment variables.
D
Hi, @peteranny. I’m Dosu, and I’m helping the tuist team manage their backlog and am marking this issue as stale.
Issue Summary:
Next Steps:
Thanks for your understanding and contribution!
P
D