Alfmob 33 implemented ci cd #7
Conversation
| FCA0B27B2CEF3EE7000339F6 /* .github */ = { | ||
| isa = PBXGroup; | ||
| children = ( | ||
| FCA0B27D2CEF3EFB000339F6 /* workflows */, | ||
| ); | ||
| path = .github; | ||
| sourceTree = "<group>"; | ||
| }; | ||
| FCA0B27D2CEF3EFB000339F6 /* workflows */ = { | ||
| isa = PBXGroup; | ||
| children = ( | ||
| FCA0B27E2CEF3F12000339F6 /* alfie.yml */, | ||
| ); | ||
| path = workflows; | ||
| sourceTree = "<group>"; | ||
| }; |
There was a problem hiding this comment.
There's no need to add the .github folder to the .xcodeproj, neither the alfie.yml file
There was a problem hiding this comment.
I think the idea is that we can edit these files while working on the project in Xcode, instead of having to open another editor.
To your point, I think we might not need to add the whole folder and just add the relevant files.
IMO we just need to be careful that these files aren't added to the app target, but I don't see any problem in adding them to the project as references. In other projects I've worked on we even create a group without folder, and add file references to it for all these CI/tooling/setup/documentation files
| lane :validate_branch do | ||
| sh("swiftlint") # Runs SwiftLint | ||
| sh("xcodebuild analyze -scheme Alfie -destination '#{ENV['IOS_DESTINATION']}'") | ||
| sh("xcodebuild test -scheme Alfie -destination '#{ENV['IOS_DESTINATION']}'") |
There was a problem hiding this comment.
perhaps use run_tests action (aka scan) ?
https://docs.fastlane.tools/getting-started/ios/running-tests/
We can also set SCAN_DESTINATION and any other env var once which then gets passed automatically to each fastlane action. Take a look here for scan's parameters, for instance.
| desc "Push a new beta build to TestFlight" | ||
| desc "Validate branch with linting, analysis, and tests" | ||
| lane :validate_branch do | ||
| sh("swiftlint") # Runs SwiftLint |
There was a problem hiding this comment.
there's a swiftlint fastlane action. I have mixed feelings about bundling swiftlint executable in the project, but I tend to prefer it being povided externally (e.g. via brew, SPM plugin, ...)
| increment_build_number(xcodeproj: "Alfie.xcodeproj") | ||
| build_app(scheme: "Alfie") | ||
| upload_to_testflight | ||
| api_key = app_store_connect_api_key( |
There was a problem hiding this comment.
I don't think we need to store the api_key, as this action stores it on the environment for subsequent actions to use (such as upload_to_testflight, match, etc)
|
|
||
| match(type: "appstore", readonly: false, api_key: api_key) | ||
|
|
||
| increment_build_number |
There was a problem hiding this comment.
we are incrementing the build number, but how is it updated after each build?
Shouldn't we get the last tag's value, extract the BN, then increment and set it on the Xcode project instead?
|
|
||
| increment_build_number | ||
|
|
||
| version = get_version_number(xcodeproj: "Alfie.xcodeproj") |
There was a problem hiding this comment.
we can and probably should store the Xcode project's path on an env var, which avoids duplication and possible errors.
No description provided.