-
Notifications
You must be signed in to change notification settings - Fork 4
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
Add task to set the project package resolution strategy #171
Conversation
7e164d8
to
e42c4c4
Compare
e42c4c4
to
c973e97
Compare
d64ef08
to
24974af
Compare
src/main/groovy/wooga/gradle/unity/traits/UnityCommandLineSpec.groovy
Outdated
Show resolved
Hide resolved
src/main/groovy/wooga/gradle/unity/tasks/ProjectManifestTask.groovy
Outdated
Show resolved
Hide resolved
src/main/groovy/wooga/gradle/unity/tasks/ProjectManifestTask.groovy
Outdated
Show resolved
Hide resolved
8c8aac6
to
5d7a831
Compare
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.
Ok maybe I asked that before. It seems that this logic will hard switch to a new strategy and leaves the changed value in place after the build is done? I also miss a lot of the property tests for the newly added tasks and task properties. I'm still a little bit confused about the test changes to be honest. Lets check this PR and the changes together.
To the model. I would like to see a class representation for the Manifest. That is not needed know but I think it is nicer to have an actual API to work against than using a object only representation. Something like this:
https://github.com/wooga/atlas-xcodebuild/blob/master/src/main/groovy/wooga/gradle/xcodebuild/config/ExportOptions.groovy
void setProjectDirectory(String path) { | ||
projectDirectory.set(layout.projectDirectory.dir(path)) | ||
} | ||
|
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 thought we decided not to add too many overloads for the setters. And in this case, because we have a few overloads we wanted to keep, was to use File
over String
. Because in the build.gradle file one can express this quite nicely with:
unity.projectDirectory = file("path/to/project")
Which is cleaner than allowing any String to be passed to the setter.
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.
Yes, good point.
def _path = projectDirectory.get().asFile.path | ||
projectPath = _path |
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.
Why the two lines? I guess you needed to debug a value?
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 was transforming the value but ended up taking that back. Will revert.
void setPackagesDir(Provider<Directory> value) { | ||
packagesDir.set(value) | ||
} |
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.
To get in line with most other getter/setter I would also add a File
setter for packagesDir
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.
Sure.
runTasksSuccessfully(taskName) | ||
|
||
then: "manifest file contains added packages" | ||
def dependencies = new JsonSlurper().parse(manifestFile)["dependencies"] | ||
dependencies["com.unity.testtools.codecoverage"] == "1.1.0" | ||
dependencies["com.unity.package"] == "anyString" | ||
|
||
where: | ||
taskName = "schonerKatzen" |
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.
Ok why is it no longer using the subjectUnderTestName
? Also I would refrain from non technical names for test values. Especialy if they show up in reports or logs. schonerKatzen
in a log output etc for tests reads like some weird error.
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.
Because this is no longer an UnityTask
. I did not want to add another TaskIntegrationSpec
.
And sure.
import wooga.gradle.unity.UnityTaskIntegrationSpec | ||
|
||
class AddUPMPackagesTaskIntegrationSpec extends UnityTaskIntegrationSpec<AddUPMPackages> { | ||
|
||
class AddUPMPackagesTaskIntegrationSpec extends UnityTaskIntegrationSpec { |
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.
Why are you no longer using the Generic setup for this task type?
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.
See above; as these tasks that modify the project manifest no longer invoke unity themselves, they are not UnityTask
s.
I don't mind making a model out of the project manifest, will do. Will also add the task integration tests. |
5d7a831
to
28f416a
Compare
8c920f2
to
c73a282
Compare
- Add generic task to modify the project manifest file - Add plugin task to ensure there's a package manifest
c73a282
to
49f25ee
Compare
Description
Adds task to modify the project package resolution strategy,
setResolutionStrategy
, according to this:(https://docs.unity3d.com/Manual/upm-manifestPrj.html#resolutionStrategy)
The task class derives from a base
ProjectManifestTask
, which is now shared with the existingAddUpmPackages
task that was previously implemented.Changes
setResolutionStrategy
plugin taskAddUPMPackages
task base layout into a base task,ProjectManifestTask