Skip to content

[PackageBuilder] Fix test target ref in manifest for external packages #620

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

Merged
merged 1 commit into from
Aug 31, 2016

Conversation

aciidgh
Copy link
Contributor

@aciidgh aciidgh commented Aug 29, 2016

This was caused due to test targets not being constructed when a package
acts as a dependency.

rdar://problem/28038874 SR-2353: Test dependencies block a package
for being used downstream

@aciidgh
Copy link
Contributor Author

aciidgh commented Aug 29, 2016

@ddunbar Should I write add functional test for this? not sure if this can be unit tested

@ddunbar
Copy link
Contributor

ddunbar commented Aug 29, 2016

I think this is important enough we need to be able to test it. What would it take to be able to mock up a PackageGraph enough to test this?

// It is unfortunate that test modules has to be constructed even when they are
// not requested by the clients but they might be referenced in the manifest file
// so that needs to be validated.
let testModules = try constructTestModules(modules: modules)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is ok that we construct test modules here, the performance cost should be negligible and I think it is actually better to not have the graph structure change depending on the use case.

@aciidgh aciidgh force-pushed the fix-test-dependencies-downstream branch 2 times, most recently from 0e19712 to adb8438 Compare August 30, 2016 02:50
@aciidgh
Copy link
Contributor Author

aciidgh commented Aug 30, 2016

@ddunbar Added a mock package graph tester

@ddunbar
Copy link
Contributor

ddunbar commented Aug 30, 2016

This is great, thanks! LGTM

We should use this to check the cross package deps too... I wonder how close we are getting to being able to drop most of the functional tests. I guess we need testing for Build first.

@ddunbar
Copy link
Contributor

ddunbar commented Aug 30, 2016

@swift-ci please test

@aciidgh
Copy link
Contributor Author

aciidgh commented Aug 30, 2016

I think it should be easily possible to run PackageBuilderTester on this since PackageBuilder is already run by the loader. I'll file a bug for investigating and start migrating cross package deps to unit testing

@aciidgh aciidgh force-pushed the fix-test-dependencies-downstream branch from adb8438 to 952a9da Compare August 30, 2016 04:35
@aciidgh
Copy link
Contributor Author

aciidgh commented Aug 30, 2016

@swift-ci please test

@aciidgh aciidgh force-pushed the fix-test-dependencies-downstream branch from 952a9da to 1a57084 Compare August 30, 2016 16:11
@abertelrud
Copy link
Contributor

LGTM

@aciidgh aciidgh force-pushed the fix-test-dependencies-downstream branch from 1a57084 to ddb040a Compare August 31, 2016 15:53
This was caused due to test targets not being constructed when a package
acts as a dependency.

<rdar://problem/28038874> SR-2353: Test dependencies block a package
for being used downstream
@aciidgh aciidgh force-pushed the fix-test-dependencies-downstream branch from ddb040a to 7c2828b Compare August 31, 2016 16:27
@aciidgh
Copy link
Contributor Author

aciidgh commented Aug 31, 2016

Tested locally

@aciidgh aciidgh merged commit dc389e2 into swiftlang:master Aug 31, 2016
@aciidgh aciidgh deleted the fix-test-dependencies-downstream branch August 31, 2016 16:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants