Skip to content
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

Merged
merged 1 commit into from
Jan 17, 2023

Conversation

Azurelol
Copy link
Contributor

@Azurelol Azurelol commented Dec 23, 2022

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 existing AddUpmPackages task that was previously implemented.

Changes

  • ADD setResolutionStrategy plugin task
  • IMPROVE AddUPMPackages task base layout into a base task, ProjectManifestTask

@Azurelol Azurelol force-pushed the add/modify_project_manifest_task branch 3 times, most recently from 7e164d8 to e42c4c4 Compare December 23, 2022 15:49
@Azurelol Azurelol force-pushed the add/modify_project_manifest_task branch from e42c4c4 to c973e97 Compare January 2, 2023 10:59
@Azurelol Azurelol marked this pull request as ready for review January 2, 2023 11:02
@Azurelol Azurelol requested a review from Larusso as a code owner January 2, 2023 11:02
@Azurelol Azurelol force-pushed the add/modify_project_manifest_task branch 11 times, most recently from d64ef08 to 24974af Compare January 4, 2023 14:21
@Azurelol Azurelol force-pushed the add/modify_project_manifest_task branch 2 times, most recently from 8c8aac6 to 5d7a831 Compare January 6, 2023 09:49
@Azurelol Azurelol requested a review from Larusso January 12, 2023 09:10
Copy link
Member

@Larusso Larusso left a 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

Comment on lines 49 to 52
void setProjectDirectory(String path) {
projectDirectory.set(layout.projectDirectory.dir(path))
}

Copy link
Member

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.

Copy link
Contributor Author

@Azurelol Azurelol Jan 13, 2023

Choose a reason for hiding this comment

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

Yes, good point.

Comment on lines 97 to 98
def _path = projectDirectory.get().asFile.path
projectPath = _path
Copy link
Member

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?

Copy link
Contributor Author

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.

Comment on lines +103 to +105
void setPackagesDir(Provider<Directory> value) {
packagesDir.set(value)
}
Copy link
Member

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure.

Comment on lines 80 to 88
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"
Copy link
Member

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.

Copy link
Contributor Author

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 {
Copy link
Member

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?

Copy link
Contributor Author

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 UnityTasks.

@Azurelol
Copy link
Contributor Author

Azurelol commented Jan 13, 2023

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

I don't mind making a model out of the project manifest, will do.

Will also add the task integration tests.

@Azurelol Azurelol force-pushed the add/modify_project_manifest_task branch from 5d7a831 to 28f416a Compare January 13, 2023 16:51
@Azurelol Azurelol requested a review from Larusso January 13, 2023 16:57
@Azurelol Azurelol force-pushed the add/modify_project_manifest_task branch 2 times, most recently from 8c920f2 to c73a282 Compare January 16, 2023 13:39
- Add generic task to modify the project manifest file
- Add plugin task to ensure there's a package manifest
@Azurelol Azurelol force-pushed the add/modify_project_manifest_task branch from c73a282 to 49f25ee Compare January 16, 2023 14:09
@Larusso Larusso merged commit 2a72e9a into master Jan 17, 2023
@Larusso Larusso deleted the add/modify_project_manifest_task branch January 17, 2023 07:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants