How to tell if a task was explicitly asked for on the command line?

[Steve_Ebersole (steve)]

I’d like to know whether a specific task was explicitly requested on the command line, but cannot find a proper way to do that. Is there?

I have already tried using StartParameter#getTasks as well as StartParameter#getTaskRequests. They work if the full task name is used. The specific task I am interested in is the Sign task, for a publication named publishedArtifacts, so I am looking for signPublishedArtifactPublication. This works for, e.g.:

gradlew signPublishedArtifactPublication ...

However, if I do this instead e.g., it will not work:

gradlew sign ...

There is no real task named sign; this is simply Gradle’s task “shorthand” handling.

As far as I can tell, there is also no way from TaskExecutionGraph to tell.

Any pointers?

[Steve_Ebersole (steve)]

I take it then there is not?

[Vampire (Björn Kautler)]

I don’t think there is more you can do halfway cleanly than to look at gradle.startParameter.taskNames and try to interpret and match it.

But actually imho you should just not care how a task was requested.

If you elaborate on the actual use-case you want to cover, there might be a better solution available.

[Steve_Ebersole (steve)]

It is related to signing. Signing requires some not-so-trivial local set up. So I am trying to avoid any config and execution for that whenever possible.

Really that only needs to happen when:

1. we publish
2. we explicitly ask to execute sign (to verify sig, test out a new config, etc)

So (1) is easy enough. (2) has been quite challenging. The closest I have been able to come is basically what you suggest - I just limited the acceptable “task names” I look for. So I recognize sign and signPublications and the full task name, but not the forms that Gradle “auto expands” (not sure what that feature is called).

[Steve_Ebersole (steve)]

Anyway, you answered - there is not. So marked that as the solution.

[Steve_Ebersole (steve)]

BTW - hibernate-orm/published-java-module.gradle at 8225ab1f9b07e3f5a315e11c639b11daf7bbf0d5 · hibernate/hibernate-orm · GitHub

[Vampire (Björn Kautler)]

Is it really that significant effort to care about excluding it?

If it is, maybe you can make it depending on some other criterion, like whether it is a snapshot version or not, or whether a special additional Gradle property is supplied, those cannot be abbreviated, so it is unambiguous. But actually that would be practically the same as requiring that the task is not abbreviated on invocation.

[Steve_Ebersole (steve)]

@Vampire

Is it really that significant effort to care about excluding it?

I mean, define “significant”. It does not make sense in those cases, so sure I’d like to avoid it. I just want to make sure no one is ever going to have a build failure when:

1. they do not have their environment set up for signing, but
2. they have not in any way requested any actions that need signing

Is that significant? Dunno. But seems desirable, to me at least.

@Vampire

If it is, maybe you can make it depending on some other criterion, like whether it is a snapshot version or not, or whether a special additional Gradle property is supplied, those cannot be abbreviated, so it is unambiguous. But actually that would be practically the same as requiring that the task is not abbreviated on invocation.

I actually started off having it disabled if SNAPSHOT. But then I could not test signing. Well I could, but I had to change the version and hope nothing I ran triggered a publish.

There was then a PR to add a setting to control this, but I hate settings. Especially settings that are completely unnecessary. The build knows when signing is needed already. Well, it would sans this “was it explicitly requested” snafu.

Anyway, let’s just call this answered and wrapped. I think what I am trying is reasonable and it is just not supported. So I’ll just have to use my “task name convention” approach.

[Vampire (Björn Kautler)]

@Steve_Ebersole

I just want to make sure no one is ever going to have a build failure when:

1. they do not have their environment set up for signing, but
2. they have not in any way requested any actions that need signing

Is that significant? Dunno. But seems desirable, to me at least.

Not just desirable, but a must imho.
I thought you do it to save configuration time.
But usually that should not be much of a problem I think.
Iirc I usually configure the singing if the properties are set and don’t if not.
And only when releasing, required is set to true so the signing will fail if it is not configured.
And if required is false, singing will be done if it is configured and not done if it is not configured.
But that shouldn’t depend on the tasks triggered explicitly, should it?

@Steve_Ebersole

I actually started off having it disabled if SNAPSHOT. But then I could not test signing. Well I could, but I had to change the version and hope nothing I ran triggered a publish.

As said above, in the typical setup you don’t disable but set required. With required set to false, signing is still done if it is configured, but skipped without error if it is not configured.

@Steve_Ebersole

Anyway, let’s just call this answered and wrapped. I think what I am trying is reasonable and it is just not supported. So I’ll just have to use my “task name convention” approach.

[Steve_Ebersole (steve)]

@Vampire

As said above, in the typical setup you don’t disable but set required . With required set to false , signing is still done if it is configured, but skipped without error if it is not configured.

Ok, this might be enough for my case. I’ll have to contemplate that some.