jenkinsci / jenkinsci/workflow-cps-plugin

Track unused struct function calls

Open
#1,740 0 comments 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
Java
Stars
186
Forks
213
Avg merge
12h 12m
Merged PRs (30d)
8

Description

As of https://github.com/jenkinsci/workflow-cps-plugin/pull/28 following the design in https://github.com/jenkinsci/workflow-aggregator-plugin/issues/295#issuecomment-3627944569 there is a problem that if a user tries to run a function intending it to be a step, but the corresponding plugin is not installed, yet there is some (typically exotic or unrelated) `@Symbol` which happens to have the same name, the function call silently succeeds.

In particular this is common with `pipeline` (the symbol for `WorkflowJob`) and `pipeline-model-definition`.

In general it would be helpful to detect that a symbol was instantiated but never actually passed to a step function. I think this could be done by having `UninstantiatedDescribableWithInterpolation` register itself (ideally with a stack trace or line number or something) using something like a UUID. `invokeStep` would then clear the registry for any such objects found (recursively) in `namedArgs`. When finishing the program, if there are any unused objects left, issue a warning that you might have been intending to call something that in fact had no effect. Too risky to make that a hard error in general since you might, for example, write something like

```groovy
def creds = string(credentialsId: 'my-token', variable: 'TOKEN')
// …
if (BRANCH_NAME == 'main') {
withCredentials([creds]) {
sh 'deploy'
}
}
```

even if it seems unlikely.

Contributor guide

Open the contributing guide

Research direction

Start by reading UninstantiatedDescribableWithInterpolation and invokeStep, then trace how namedArgs and program completion are handled. Define how instances register and how invokeStep clears objects passed recursively through namedArgs. Done means unused instances produce a warning at program completion without turning the condition into a hard error.

Written by the indexing model from the issue text.

Assessment

Tech stack
groovy, java
Domain
backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.