### Short description
We've noticed the scheme generation is not always stable. The order of testable targets in a scheme could change after re-generating the project.
It's reproducible when multiple testable targets depend on the same target (framework, or app) within a single project.
i.e.
- ProjectA:
- AppTarget
- UnitTestsTarget (dependencies: [AppTarget])
- UITestsTarget (dependencies: [AppTarget])
### Solution
- Sorted testable targets
- Updated one of the unit tests to reproduce the issues, and avoid regression in the future
- Updated the integration tests to cover multiple testable targets user case
Resolves: https://github.com/tuist/tuist/issues/660
- Ensure the `LD_RUNPATH_SEARCH_PATHS` build setting is set for test targets
Test Plan:
- Generate `fixtures/ios_app_with_tests`
- Verify the generated project's test target contains a valid `LD_RUNPATH_SEARCH_PATHS` build setting
* Delete embed logic
* Add methods to read the dsym path & bcsymbolmap paths from a framework
* Place the tests in the right test case
* Implement EmbedScriptGenerator
* Test EmbedScriptGenerator
* Extract methods that interact with the system into metadata provider utilities and fix tests
* Include output paths
* Test FrameworkMetadataProvider
* Test PrecompiledMetadataProvider
* Add more tests
* Create fixture project
* Add acceptance test
* Address comments
* Use Xcode 11.1
* Update Package.resolved
* Update XcodeProj
* Make the tuistenv install test more resilient
* Add System.shared
* Implement TuistTestCase, TusitUnitTestCase, and refactor all the tests to use those classes instead.
Make some progress
Refactor tests to use TuistUnitTestCase
Create TuistTestCase
* Fix some tests
* Update the documentation to indicate that there is more than one integration tests target
* Update the CHANGELOG
* Indicate the product that we build for release
* Remove unnecessary methods
* Add command to output the graph to the standard output
* Make Graph and nodes conform Encodable
* Print the graph as a json
* Some fixes after rebasing
* Pass file and line arguments
* Keep models and attributes as internal
* Extract the node classes into their own files
* Add DotGraph* elements
* Extract FrameworkNode from GraphNode
* Add tests
* Address comments
- Adding Xcode10 constants to maintain backwards compatibiltiy (Xcode 11 is still in beta!)
Test Plan:
- Verify unit tests pass via `swift test`
- Verify acceptance tests pass via `bundle exec rake features`
### Short description
Update XcodeProj version to point to current master 6029dac06eb48cc29c762965efebddb5d6c2a496 (2019-05-21).
Includes "Add SWIFT_COMPILATION_MODE and CODE_SIGN_IDENTITY build settings" https://github.com/tuist/xcodeproj/pull/417.
Part of https://github.com/tuist/tuist/issues/160
### Short description
As mentioned in https://github.com/tuist/tuist/issues/160, currently, Tuist only supports debug and release build configurations. This can be seen as a limitation for some projects. We'd like to avoid this limitation and allow users to control the configurations themselves and base them on xcconfig files if needed.
### Solution
Added `Settings` property to `Project` and `Target` generator models. `Settings` contains `base` property for settings that are common for all the configurations. `configurations` property stores dictionary mapping `BuildConfiguration` (i.e. Release, Debug, Beta etc.) to `Configuration`. The structure won't preserve the order of the configurations but can help avoid situation when the same configuration is set twice (which would require additional linting). Maintaining the original order would be particularly difficult in cases when the defined configurations orders are different in project and target settings. To keep the ordering stable, the generator sorts the configurations alphabetically.
To make the implementation backward compatible, `GeneratorModelLoader` always passes `release` and `debug` configurations with the settings defined in the manifest.
```swift
return TuistGenerator.Settings(base: base, configurations: [.debug: debug, .release: release]
```
- Updating SwiftPM dependency
- `asString` has been renamed to `pathString`
- `Utility` module has been renamed to `SPMUtility`
Test Plan:
- Verify unit tests pass `swift test`
- Verify acceptance tests pass `bundle exec rake features`
* Support Swift 5
* Fix test
* Don't check if the versions match when both local and remote versions are greater or equal than 5
* Updating fixtures for Swift 5 support
- Included a build script to allow re-creating the pre-built `Framework2` framework
- Updated build script for pre-built static library to require less manual steps
* Updates for Swift 5
- `swift package tools-version --set-current`
* Relaxed error output checks in acceptance tests
* Adding trace for acceptance test (to aid troubleshooting)
* skipping build during error message acceptance test
- Adding a step to build tuist separately ahead of calling run
- When running tuist via `swift run` we now skip the build
* Disable Swiftformat
- Introducing a `GeneratorModelLoader` component responsible for obtaining the model objects required by the `TuistGenerator` library
- To support this, the models are being decoupled from the manifest definitions (and the JSON representation)
- The conversion between the manifest and model types takes place within the model loader
Test Plan:
- Ensure unit tests continue to pass `swift test`
- Ensure acceptance tests pass `bundle exec rake features`
- Verify projects within the `fixtures` directory are still correctly generated when performing `tuist generate`
- Adding a new library `TuistGenerator` with stubbed implementation
Test Plan:
- Ensure Tuist continues to build `swift build`
- Ensure unit tests pass `swift test`
* Remplace ReactiveTask with SwiftShell
* Update CHANGELOG
* Remove Result import
* Fix issue with UpCarthage don't running when the Cartfile.resolved is missing
* Update CHANGELOG
* Define force argument
* Add documentation
* Update Installer to accept force installs
* Add tests
* Define models
* Add the up attribute to the project model
* Add models to TuistKit
* Include up in the manifest generated by the init command
* Implement HomebrewCommand
* Re-organize commands into multiple files
* Reorganize folders
* Implement up command, print a warning when running generate and the environment is not ready and add some tests
* Test Homebrew command
* Allow passing the working directory to System
* Rename UpCommand to Up
* More renaming
* Define UpCarthage and UpYarn
* Print a warning from the focus command
* Implement UpCarthage
* Define MockUp
* Format
* Don't print a warning if the environment is not met
* Solve conflicts after rebasing
* Lint UpCustom
* Implement UpCustom
* Add Carthage util to update dependencies and get the list of outdated ones
* Test UpCarthage
* Remove integration tests from the package
* Add -p argument to the Up command
* Some polishing
* Add option to generate the projects and workspaces in the ~/.tuist/DerivedProjects directory
* Remove unnecessary import
* Test ProjectDirectoryHelper
* Update CHANGELOG
* Remove unnecessary line
* Bump xcodeproj to 6.0.0
* Remove warning
* Get tests passing
* Don't import xcodeproj with testable
* Add entry to changelog
* Build with Xcode 10 on CI
* Add .swift-version file
* Fix test
Pedro Piñera