-
Notifications
You must be signed in to change notification settings - Fork 824
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support test target for local Swift Package #1074
Conversation
Package.resolved
Outdated
"branch": null, | ||
"revision": "94e55232d227f9d78b811c98cb2e5d0cbd08987b", | ||
"version": "7.22.0" | ||
"branch": "main", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We shouldn't use an unstable version.
This PR may depend on this patch.
Allows passing BuildableIdentifier
String to BuildableReference
initializer by freddi-kit · Pull Request #605 · tuist/XcodeProj
It's better to distribute newer XcodeProj.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also wanna use new stable XcoreProj version with my patch, so I will modify it after new version released.
That's why this Pull Request is still Draft.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have two comments about this PR:
-
Is this feature limited to test targets? I think we can relax the limitation for non-test targets.
-
Since this change,
ProjectName/TargetName
syntax represents a reference to a .xcodeproj or a SwiftPM package, right? Then, what happens when the given project.yml is like below:
projectReferences:
Foo:
path: ./Foo.xcodeproj
packages:
Foo:
url: ./Elsewhere/Foo
In your implementation, SwiftPM package version will be chosen, but it's not clear for users.
So we should have a single namespace for external project names or we can have a new syntax to represent a target reference for SwiftPM, but I have no idea to represent such structure with current project.yml syntax, sorry
Thanks, basically, I totally agree with your ideas. About 1., we can expand to another thing which using And currently, my changes cause ambiguous format ("/" for project and package), as you explained 2, so I'm concerning change the format a little more clear. |
I have an idea for solving these 2 concerns: Having a new Yaml(JSON) format for I feel this discussion is based on how XcodeGen/Sources/ProjectSpec/TargetReference.swift Lines 20 to 36 in 3757f82
And used for many places like I think we can change
What do you think about it? |
+1 for adding a new syntax in TargetReference 👍 |
@kateinoigakukun @giginet
Please help review it, Thanks |
@yonaskolb @freddi-kit Thanks for your work here! Can we get this work landed soon? I am running into this exact problem and a fix in mainline XcodeGen would be much appreciated! |
Ops, sorry for leaving it so long time. I worked on it but I stopped because it has some difficulty to achieve it. This change make the project spec confusable so I was finding a way to solve it. I have the motivation and I probably find out the way to do it without making spec complex. Let me touch you until this week! |
@freddi-kit Could you find a way in order to solve it in an easy way? We're waiting for it. :))) |
I'm sorry for waiting you for long time, this difficulty is about the internal API things and I just commited! |
Really looking forward to this. Any idea when you'll find time going over these changes @yonaskolb ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this again @freddi-kit, looks good to me! Only thing I'm slightly hesitant about is the syntax for declaring a test target is a bit verbose with the nested target.
testTargets:
- target:
package: XcodeGen/XcodeGenKitTests
parallelizable: true
One other option would be to decode the TestableTargetReference at the top level, but I think how you have it is ok, and makes for cleaner code.
testTargets:
- package: XcodeGen/XcodeGenKitTests
parallelizable: true
What I would like to see though is some parsing and validation tests to cover this (SpecLoadingTests.testProjectSpecParser, ProjectSpectTests.testValidation), and then we can get this merged in! 👍
Docs/ProjectSpec.md
Outdated
targets: | ||
- Tester1 | ||
- name: Tester2 | ||
parallelizable: true | ||
randomExecutionOrder: true | ||
skippedTests: [Test/testExample()] | ||
- target: | ||
package: APIClient/APIClientTests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
package: APIClient/APIClientTests | |
package: APIClient/APIClientTests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not really consistent in the way the current yml is constructed. Is there a specific reason why this is indented here?
Docs/ProjectSpec.md
Outdated
A target can be one of a 2 types: | ||
|
||
- **name**: **String** - The name of the target. If you want to specify local swift package, please use `target:`. | ||
- **target**: **[Testable Target Reference](#target-reference)** - The information of the target. You can specify more detailed information than `name:`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This link to the Testable Target section is incorrect here. It should be:
**[Testable Target Reference](#testable-target-reference)**
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's right, nice find 👍
@freddi-kit I'd be happy to open up a PR with the requested parsing and validation tests if you'd like some help getting this across the finish line |
FYI, I updated our project to point to this branch and successfully used the new functionality! 🚀 Looking forward to getting this in the mainline |
@freddi-kit I see the PR has been approved, Could you please update/merge it. |
Hi everyone, I was curious if this is still planned to be updated/merged at some point? |
import Foundation | ||
import JSONUtilities | ||
|
||
public struct TestableTargetReference: Hashable { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of introducing TestableTargetReference
would it be possible to just enhance TargetReference
. I'm asking because build targets can also be in local Swift Packages and not just test targets?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is because we already have packages:
things which is almost same with targets:
but for only swift package. And I tried to do so but there is a problem that it make confuses with packages
. I wanna keep them clear as possible
I used truecaller/XcodeGen.git, but I don't see any package in testTargets show on .xcscheme
but this way work.
|
Is there any progress on this ticket? I would be happy to help. We currently have a modular setup like this:
And I would like to create an
I think I have the perfect example to try out this pull request, so let me know if I can help! |
I'm sorry for making you waiting so long time, I finally fixed comments from @yonaskolb, please check. |
66ff567
to
c62277f
Compare
ops. I closed PR by mistake and it looks i cannot reopen it, please wait |
Reopened #1169 |
Close: #1050
note: This PR needs to wait for releasing new version of tuist/XcodeProj with tuist/XcodeProj#605