Checking whether a step from a plugin is in actual use in an instance

[Tim Van Holder]

Hi,

I maintain a plugin (dotnet-sdk) that mostly provides a global tool and associated wrapper.

But it also has a bunch (currently 11) convenience steps that can be used (instead of the wrapper plus bat/pwsh/...).

I got a ticket saying that this caused a bit of a clutter for freestyle jobs, because the list popped up by "Add build step" gets pretty long, which was fair enough. It turned out to be very easy (using isApplicable()) to have each of the steps optionally "hide" itself based on a flag in a GlobalConfiguration.

However, that only prevents it from being added to a freestyle job (using the UI anyway); it does not seem to affect steps that are already in use.

So I was wondering if it was considered frowned upon to scan through all freestyle jobs to see if a particular step is in active use somewhere, and if not, what the typical performance implications are. I was thinking of adding such a check in a doCheck for each of the checkboxes in the GlobalConfiguration, so that if you uncheck the Foo step, it can validate it with a warning "this step is currently in use by N project(s)". I'm just not sure whether that's considered a no-no, and if not, how such a check would scale to a large instance with hundreds (or thousands, if that's likely?) of projects.

Any advice would be helpful.

[Daniel Beck]

On Mon, Apr 11, 2022 at 11:53 PM Tim Van Holder <tim.va...@gmail.com> wrote:

I maintain a plugin (dotnet-sdk) that mostly provides a global tool and associated wrapper.

But it also has a bunch (currently 11) convenience steps that can be used (instead of the wrapper plus bat/pwsh/...).

I got a ticket saying that this caused a bit of a clutter for freestyle jobs, because the list popped up by "Add build step" gets pretty long, which was fair enough. It turned out to be very easy (using isApplicable()) to have each of the steps optionally "hide" itself based on a flag in a GlobalConfiguration.

Not what you're asking for, but have you considered migrating to a single ".NET" build step that offers 11 modes? That would cut down on top-level options offered by default and make the list friendlier for people who need this variety.

[Tim Van Holder]

I did consider that, but I'm currently using SimpleBuildStep to provide the steps to both freestyle and pipeline contexts.

If I make that one step, that would make the experience in pipelines rather messy, with lots of properties that would only apply for a specific combination of other properties.

(And it would also make the jelly quite complicated in order to hide/show various bits depending on other bits.)

Unless there's a relatively simple way to have a build step for freestyle that would essentially then have a dropdown for the 11 "real" steps which then shows their configuration when selected.

Then the top-level "add build task" list stays clean, with minimal extra effort for the user (an extra dropdown to select from), and keeping the code clean as well (just a simple class to do the forwarding).

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtJ0J%2BQmYPrZV_j2tLJ4te4w0T%3D-ipB8LWAxiFLxsM-Kiw%40mail.gmail.com.

[Jesse Glick]

On Tue, Apr 12, 2022 at 1:40 PM Tim Van Holder <tim.va...@gmail.com> wrote:

a relatively simple way to have a build step for freestyle that would essentially then have a dropdown for the 11 "real" steps which then shows their configuration when selected

This is straightforward. (`ui-samples-plugin` may be instructive.) Just an abstract `Describable` supertype for the real things, and the `config.xml` for the `Builder` can have a `f:dropdownDescriptorSelector` and maybe nothing else. Each real thing has its own `config.jelly`. If you also add `@Symbol`’s, then for Pipeline you would get syntax like

dotnet tool: makeAssembly(assemblySpecificOption: true), genericOption: 'whatever'

[Tim Van Holder]

Daniel offered a similar suggestion off-list. I'll have a look once I get a release out with what I have now.

One question though - what would the migration path be like?

Can a plugin include code that will update a freestyle project that uses the DotNetFoo builder to use the DotNet builder with a Foo argument instead?

I would assume I'd normally have read-only access to the freestyle jobs.

I suppose I could just keep both around, with isApplicable() for the old ones returning false (so that existing uses remain valid, but only the new builder could be used for new steps), but an automatic upgrade would be nice too.

I'd have to keep them around for pipeline use anyway; is there anything in Jenkins that will report warnings for use of deprecated steps in a pipeline job? There's no isApplicable() there to keep them from being written in scripts, so if I can at least have the build report that the new steps should be used instead, that's something. I wouldn't want to keep the old builders around in perpetuity (even if they can become simple wrappers around the new one).

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3eG-v5vNV4ScKYLPHRSCgCheLjGJsQ9H7_JVCbmTx6Xw%40mail.gmail.com.

[Jesse Glick]

On Mon, Apr 18, 2022 at 4:38 AM Tim Van Holder <tim.va...@gmail.com> wrote:

Can a plugin include code that will update a freestyle project that uses the DotNetFoo builder to use the DotNet builder with a Foo argument instead?

It is possible with an `@Initializer`.

I'd have to keep them around for pipeline use anyway

Correct.

is there anything in Jenkins that will report warnings for use of deprecated steps in a pipeline job?

No, but you could print a message to a `TaskListener` in case the user is paying attention. If you want to be more aggressive, there is always `AdministrativeMonitor`.

[Daniel Beck]

> On 18. Apr 2022, at 10:38, Tim Van Holder <tim.va...@gmail.com> wrote:
>
> Can a plugin include code that will update a freestyle project that uses the DotNetFoo builder to use the DotNet builder with a Foo argument instead?

Potentially doable via readResolve as well.

[Jesse Glick]

On Mon, Apr 18, 2022 at 3:16 PM 'Daniel Beck' via Jenkins Developers <jenkin...@googlegroups.com> wrote:

Potentially doable via readResolve as well.

Unfortunately you cannot do this sort of thing via `readResolve` so far as I know.

Ideally there would be some API which you could call from `readResolve` or otherwise mark a class which, if loaded in the context of some top-level model object (in this case `Project`), would trigger a callback after the top-level load completes, which you could use to immediately rewrite the reference, add to `OldDataMonitor`, etc.

In the absence of that, your only option is to add a global initialization hook which scans all build steps in all projects. Obviously this adds startup overhead for everyone who installs your plugin, even if it is unused. You could use a `GlobalConfiguration` (or simple `FileBoolean`) to track whether the translation has been run before.

Another common use case is migrating `Secret` to `credentialsId`.