What version are you building against? I think recent weekly (and the
upcoming LTS) has that help issue fixed
RE: design library and warnings, mind filing an issue for that?
On Sun, 14 Aug 2022 at 17:14, Tim Van Holder <tim.vanhol...@gmail.com>
wrote:
> Hi,
>
> I'm in the process of adjusting a plugin that has a dozen build steps to
> use a single step instead (all steps are subcommands of a single executable
> and/or subcommands of those subcommands). There are two parts to this.
>
> The first is writing the new step/builder. The idea is to use a new
> extension point / describable for each "level" of command. This mostly
> seems to work fine.
> However, I ran into two issues so far:
>
> 1. you can use @Symbol to assign a simple symbol to make things like "
> dotnet(buildServer(shutdown())" work; but there seems to be no
> checking that such a symbol is valid/usable, neither at build time nor at
> run time. For example, I had "package" as symbol (for "dotnet list
> package"); it was only when I tried to use it in a pipeline that any
> error occurred (because package is a reserved word). It would
> certainly be useful to get a diagnostic for that at maintenance/build time
> (this assumes Groovy is the only supported/intended context for those
> symbols; otherwise checking for reserved words might be tricky).
> 2. I'm using <f:dropdownDescriptorSelector> for the nested
> describables which mostly works nicely. However, this does not surface any
> help files for the selected describable in the UI. Is that a bug or by
> design? I tried adding
>
> <div class="setting-main help-sibling">
> <f:helpLink url="${descriptor.getHelpFile()}"/>
> </div>
>
> to the config.jelly for such a describable, but although that does
> render the question mark icon, it doesn't actually do anything when
> clicked. If it's a bug (or missing feature), what's the appropriate place
> to report it? Otherwise, what's the best way to make it work? Should I copy
> the dropdownDescriptorSelector jelly and modify that?
>
>
> The second part is dealing with deprecating the "old" build steps.
>
> For free-style projects this was very easy. I just adjusted their
> descriptors to return false from isApplicable(). That hides them from the
> UI for new configuration but leaves existing projects usable. I then added
> a "this step is deprecated" banner to their config.jelly (note: it would be
> really useful if the Jenkins Design Library also documented style elements,
> such as using a div with class="alert alert-warning" for a warning
> banner). Great - clutter removed from the "Add build step" UI.
>
> The only thing that would be additionally useful is an automated migration
> step; I wonder if there's any way I could have a button/link in the
> config.jelly that would allow me to construct the new step based on the old
> step's properties and have the UI take that new step into account for the
> project being edited?
>
> However, these are all Builders implementing SimpleBuildStep to be usable
> from pipelines as well. And there seems to be no way to mark those as "do
> not use". While the snippet generator does have a "deprecated/advanced"
> section, that is entirely based on a StepDescriptor implementing
> isAdvanced() - but these are Builders, so they have no StepDescriptor.
> What are my options for this? I don't think I can just have a second
> descriptor for the same class, moving the @Symbol to that one. So my only
> option would seem to be to essentially create a new set of Steps just so
> they could have descriptors marking themselves as advanced - but that would
> involve the symbols being associated with those new classes; would that
> break anything? The old class would remain a Builder and executable the
> same way, so if the old class name got persisted anywhere (e.g. for a job
> that was suspended), that *should* still work. Or should I just not care
> about clutter in the snippet generator interface at all?
>
> I do still think it would be a useful thing if there was a way to set up a
> builder/step so that the snippet generator hides it in its entirety. This
> could be as easy as calling descriptor.isApplicable, passing in either a
> "fake" AbstractProject implementation (SnippetGeneratorProject or
> something) or by passing in whatever AbstractProject applies to pipeline
> projects.
> Alternatively, perhaps it could move steps to the deprecated/advanced
> section if they are marked @Deprecated? Or is all this just a consequence
> of the steps in question getting run via a meta-step?
>
> --
> 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-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAKMi--C2%3Dhm77jbPZ1zEvVeZ_8ZMXhg8zzW5%2Bkfi2FeYd%2BExfA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAKMi--C2%3Dhm77jbPZ1zEvVeZ_8ZMXhg8zzW5%2Bkfi2FeYd%2BExfA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BicRDwe4KxqpsWm5KXgvegyR_0iF4cGNVLw9ideY1YBYhQ%40mail.gmail.com.
