- The info plist generator is now a project mapper
- This helps keeps project modifications and side effects consistent to some of the others introduced
- Updated `Constants` to create a nested hierarchy for `DerivedDirectory` to allow grouping all related constants
- Updated side effect descriptions such that they are all `CustomStringContvertible` to allow using them in verbose logs
Test Plan:
- Run `tuist generate` within `fixtures/ios_app_with_watchapp2`
- Verify the Info.plist files continue to be generated to the `Derived/InfoPlists` directory
* Provide path for XCTest.framework
Add unit tests for XCTest framework
* Fix swifit lint errors
* Update fixture to test XCTest sdk
* Add new .sdk dependency
* Update the documentation
Co-authored-by: Maksym Prokopchuk <rowwingman@gmail.com>
Co-authored-by: Kassem Wridan <kwridan@bloomberg.net>
Co-authored-by: Pedro Piñera <pedro@ppinera.es>
* Generate tuist generated file into workspace to solve ambiguity.
* Edit changelog.
* Move generating tuist-generated file to TuistKit.
* Fix BuildGraphInspector tests.
* Add test for no tuist workspace present.
* Add loadProjectWorkspace method to add tuist-generated to project workspace.
* Run swiftformat.
* Add empty AutogeneratedSchemesGraphMapper
* Don't generate the schemes at generation time
* Implement AutogeneratedSchemesGraphMapper
* Update CHANGELOG
* Remove unnecessary method
* Turn the graph mapper into a project mapper
* Address some comments
Co-authored-by: Pedro Piñera <pedro@ppinera.es>
* Adds `language` and `region` to `TestAction` types
* Update CHANGELOG.md
* Fix issues after rebasing from master and update documentation
Co-authored-by: Maciej Piotrowski <maciej.piotrowski@allegro.pl>
Co-authored-by: Pedro Piñera <pedro@ppinera.es>
* Update the models in ProjectDescription to add support for enabling the main thread checker
* Set disableMainThreadChecker depending on the given diagnostic options
* Fix tests
* Add unit tests
* Update documentation
* Update CHANGELOG
Co-authored-by: Pedro Piñera <pedro@ppinera.es>
* Remove CFBundleExecutable from iOS resource bundle target plists
- When generating the plist file for an iOS resource bundle target the key `CFBundleExecutable` should be omitted
- Having it included causes a validation error when uploading application to the app store
```
Error 1: ITMS-90535 - Unexpected CFBundleExecutable Key
```
Test Plan:
- Run `tuist generate` within `fixtures/ios_app_with_framework_and_resources/StaticFramework`
- Verify the generate info plist in `Derived` directory does not contain the `CFBundleExecutable` key
* Update changelog
Resolves https://github.com/tuist/tuist/issues/1225
### Short description
Add support for localized sources(eg `.intentdefinition`)
### Solution
Add localized sources variant group as build files to the sources build phase instead of the individual files. This solution is consistent with how localized resources are handled within the resources build phase.
* Add SettingsDictionary typealias for [String: SettingValue]
* Add SettingsDictionary functions to avoid using typed strings
* Add new SettingsDictionary functions to Changelog
* Improve changelog with links to PRs and usernames
(of contributors with 3+ PRs)
* Link also to PRs in Changelog
* Add documentation for SettingsDictionary
* Minor update to a SettingsDictionary transformer
* Update Changelog PR number
* Apply PR comments - part 1
* Apply more PR comments - part 2:
- Make SettingValue conform to ExpressibleByBooleanLiteral
- Add tests
- Change code signing methods
* Fix linting in SettingsTests
* Update Docs and Changelog
* Remove some of the SettingsDictionary functions
* Add SettingsDictionary functions table to website docs
* Add support for returning side effect descriptors from mappers
* Implement GraphMapperProvider to provide the mapper to be used depending on the config
* Add GraphMapperProviderTests
* Update CHANGELOG
* Test if the descriptors are concatenated in the right order
* Fix CHANGELOG. Some updates showed up in the wrong section
### Short description 📝
In our projects at @AckeeCZ we usually use customized schemes that add pre-build actions which generate inputs for other build phases. Without those inputs, project is not compilable, thus default generated schemes do not make a real sense and only confuse newcomers.
### Solution 📦
Idea is to add possibility to skip generation of those schemes by specifying a new configuration option `disableAutogeneratedSchemes`. This will ensure only custom schemes are generated.
### Implementation 👩💻👨💻
- [x] add new property `disableAutogeneratedSchemes ` to `Config`
- [x] check this property in `SchemesGenerator`
- [x] update existing tests
- [x] update docs
When a project has a scheme that runs multiple test targets that rely on
the `Embed Precompiled Frameworks` script then the new build system
fails because there are multiple commands that produce the same target
file.
This commit prevents adding symbol files to the input/output file lists
for test targets to prevent this error from occuring.
Fixestuist/tuist#919
Resolves: https://github.com/tuist/tuist/issues/1144
- Generating a project that has a .sdk dependency will result in in a project that includes a relative path to the SDK directory from the source root (which will be different on different machines).
```diff
buildSettings = {
ASSETCATALOG_COMPILER_APPICON_NAME = AppIcon;
CODE_SIGN_IDENTITY = "iPhone Developer";
ENABLE_PREVIEWS = YES;
+ FRAMEWORK_SEARCH_PATHS = (
+ "$(inherited)",
+ "$(SRCROOT)/../../../../../../../Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/System/Library/Frameworks",
+ "$(SRCROOT)/../../../../../../../Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib",
+ );
INFOPLIST_FILE = "Support/App-Info.plist";
LD_RUNPATH_SEARCH_PATHS = (
"$(inherited)",
"@executable_path/Frameworks",
);
PRODUCT_BUNDLE_IDENTIFIER = io.tuist.App;
PRODUCT_NAME = App;
SDKROOT = iphoneos;
SUPPORTED_PLATFORMS = "iphonesimulator iphoneos";
SWIFT_ACTIVE_COMPILATION_CONDITIONS = DEBUG;
SWIFT_COMPILATION_MODE = singlefile;
SWIFT_OPTIMIZATION_LEVEL = "-Onone";
SWIFT_VERSION = 5.1;
TARGETED_DEVICE_FAMILY = "1,2";
};
name = Debug;
};
```
- This appears to be a side effect of some tidy ups to `GraphDependencyReference` which accidentally removed the filtering `LinkGenerator` used to perform to only add paths to precompiled frameworks and libraries
- To help make the usage clearer the `path` variable has been renamed to `precompiledPath`
- Tests have been updated to catch this in the future
Test Plan:
- Run tuist generate within `fixtures/ios_app_with_sdk`
- Open the generated project
- Inspect the `FRAMEWORK_SEARCH_PATH` build setting
- Verify it doesn't contain entires for the relative SDK paths
- Each project within a workspace is currently generated independently and non of the project share any mutable state
- The graph is static during the generation process
- As such one option to gain some overall performance improvement is to generate project concurrently as well serialise them to disk concurrently.
- An additional stress test was added to ensure there were no concurrency issues during workspace generation
- The test logger needed some small thread safetey improvement
- Fix concurrency issues in Atomic
- Leverage execution contexts to control threading behavior of components
- Update `XcodeController` to minimize synchronization calls (via `Atomic`)
Test Plan:
- Verify all automated tests pass
- Stress test tuist via running this script in the `fixtures` directory
```sh
#!/bin/bash -e
# skip fixtures that are testing failure cases
declare -a skipped_fixtures=(
"invalid_workspace_manifest_name"
"ios_app_with_incompatible_dependencies"
"ios_app_with_incompatible_xcode"
"ios_workspace_with_dependency_cycle"
)
# Generate all fixtures in a loop
for i in {1..20}; do
for f in *
do
if [[ ! " ${skipped_fixtures[@]} " =~ " ${f} " ]]; then
if [[ -d $f ]]; then
echo ">> Generating: $f"
swift run tuist generate --path $f
echo ""
fi
fi
done
done
```
Part of: https://github.com/tuist/tuist/issues/1093
- Leverage simpler string contains check to determine if a path is nested within an `xcassets` or `lproj` container
- The check on the `pathString` can be done directly as `AbsolutePath` ensures no trailing `/` in its `pathString` as such checking for `.xcassets/` or `.lproj/` can act as a suitable faster replacement of the `regex` check that was previously used.
Test Plan:
- Run `tuist generate` within `fixtures/ios_app_with_framework_and_resources`
- Verify the generated projects contains the xcassets and localized string files as before
Resolves https://github.com/tuist/tuist/issues/1063
### Short description 📝
New Files created by Xcode use the Organization name set in the project file for copyright notices. The organization was left blank before this PR.
### Solution 📦
It is now possible to optionally pass the organization name to either the `Project` initializer or more generally in `Config`. The latter will override the former if set.
### Implementation 👩💻👨💻
- [x] Add new `organizationName` argument to Project
- [x] Add new `organizationName` GenerationOptions case to pass to Config
- [x] Use project `organizationName` during pbxproj generation via attributes
- [x] Add Tests
### Short description
When using `TuistGenerator` as a library, the generator component performs several actions:
- Loading of the graph
- Linting the graph
- XcodeProj generation
- Writing generation artifacts to disk
- Post generation actions
While convenient it doesn't offer flexibility to perform any custom linting or post processing on the generated XcodeProj representations or to selectively leverage some of those actions without the others.
### Solution
Based on a few early prototyping rounds on [tuist-labs](https://github.com/tuist/tuist-labs/tree/prototype/pipelines) and discussions on modularising Tuist even further, we can split the responsibilities of the generator to provide more flexibility and simplicity.
- Update the generator to return descriptors (it doesn't directly perform any operations - it's side effect free)
- Create a dedicated component to write those descriptions to disk as well as perform any required side effects
- Move some of the interactors that performed side effects out of the xcodeproj generation to help group them (e.g. CocoaPods / Swift PM)
- Create a new top level component to orchestrate all those steps to achieve the previous behaviour
_**Note:** These changes should have no impact on end users of Tuist_
### Implementation
- [x] Prototype `Descriptors` by having existing components return descriptors instead of performing actions (initially as duplicate methods for testing/prototyping)
- [x] Integrate a prototype of a high level `ProjectGenerator` that performs all the previous tasks with the `tuist generate` command
- [x] Verify acceptance tests don't flag any regressions
- [x] Delete duplicate methods (the non-descriptor) variants and update their corresponding unit tests
- [x] Integrate the updated generator with the other tuist commands
- [x] Come up with better component names to clarify their purpose _(current names were temporary to avoid name collisions however could be confusing)_
- [x] Update change log
### Test Plan
- Verify all acceptance tests pass
- Test out running `tuist generate` on any of the fixtures
Kas