This message was deleted.
# community-support
s
This message was deleted.
v
You cannot. You cannot even yet add a second
Test
task. It is currently 111 relationship test suite / test target / test task. 😞
You can independently declare some
Test
task, but not "in the scope of the test suite".
j
I guess I shouldn't care much about that until Gradle won't let us customize suites?
v
"until ... won't"?
j
Damn dictionaries and swipe typing on the phone.
I guess I'll just proceed with custom Test task type and see what'll happen.
v
Yeah, but did you mean "as long as ... won't" or "until ... will"?
j
Until will 🙃
v
"shouldn't care" depends on what you mean. If you just register a custom task, it's maybe unlucky that you also have the non-operable default task?
And you should care in so far as to raise your voice for the need. 😄 I guess there is a ticket about it, but I don't know it, and if not maybe it would make sense to create one.
j
Alternatively, I'll expose something that'll decorate the base Task with whatever is needed. On demand. To do not create any unexpected situations in the default development flow.
v
Yeah, but again depends on what you mean exactly. 🙂 If "decorate" means some execution time action that changes task configuration, that would be a big no-no. And especially with configuration cache even illegal.
j
Not in the execution time but still in the configuration phase.
v
👌
v
I see a
doFirst
that changes
classpath
,
jvmArgumentProviders
, and `systemProperty`s, that is execution time.
And iirc, system property values are not automatically task inputs, so you might need to additionally declare those values as
inputs.property
that up-to-date checking and caching works properly
j
Yup, but this is still 1.x
v
👌
j
But the
inputs.property
is something I should review.
👌 1