Missing `def` keyword in groovy
Noticed the following warning messages in the Jenkins job.
Did you forget the `def` keyword? WorkflowScript seems to be setting a field named SPEC (to a value of type String) which could lead to memory leaks or other issues.
Did you forget the `def` keyword? WorkflowScript seems to be setting a field named dockerAgents (to a value of type ArrayList) which could lead to memory leaks or other issues.
Did you forget the `def` keyword? WorkflowScript seems to be setting a field named dockerAgentLabel (to a value of type String) which could lead to memory leaks or other issues.
Did you forget the `def` keyword? WorkflowScript seems to be setting a field named LABEL (to a value of type String) which could lead to memory leaks or other issues.
Did you forget the `def` keyword? WorkflowScript seems to be setting a field named LABEL (to a value of type String) which could lead to memory leaks or other issues.
...
Did you forget the `def` keyword? WorkflowScript seems to be setting a field named dynamicAgents (to a value of type ArrayList) which could lead to memory leaks or other issues.
@annaibm could you take a look? Thanks
There are many cases, and I did not list them all. Please feel free to do it in a couple of batches.
I think we can use @Field annotation for global variables:
https://stackoverflow.com/questions/6305910/how-do-i-create-and-access-the-global-variables-in-groovy
Note: @Field cannot be initialized before params is populated by Jenkins.
Failed with NullPointerException:
@Field String SDK_RESOURCE = params.SDK_RESOURCE ? params.SDK_RESOURCE : "releases"
Correct:
@Field String SDK_RESOURCE
SDK_RESOURCE = params.SDK_RESOURCE ? params.SDK_RESOURCE : "releases"
Still a problem
https://ci.adoptium.net/job/Grinder/13110/console
[Pipeline] echo
19:41:19 Saving Grinder_rerun/313/**/*.tap file on jenkins.
[Pipeline] archiveArtifacts
19:41:19 Archiving artifacts
19:41:20 Recording fingerprints
[Pipeline] findFiles
[Pipeline] readFile
Did you forget the `def` keyword? Script1 seems to be setting a field named match (to a value of type Matcher) which could lead to memory leaks or other issues.
Did you forget the `def` keyword? Script1 seems to be setting a field named match (to a value of type Matcher) which could lead to memory leaks or other issues.
Did you forget the `def` keyword? Script1 seems to be setting a field named match (to a value of type Matcher) which could lead to memory leaks or other issues.
Did you forget the `def` keyword? Script1 seems to be setting a field named match (to a value of type Matcher) which could lead to memory leaks or other issues.
Did you forget the `def` keyword? Script1 seems to be setting a field named match (to a value of type Matcher) which could lead to memory leaks or other issues.
Did you forget the `def` keyword? Script1 seems to be setting a field named match (to a value of type Matcher) which could lead to memory leaks or other issues.
Did you forget the `def` keyword? Script1 seems to be setting a field named match (to a value of type Matcher) which could lead to memory leaks or other issues.
Did you forget the `def` keyword? Script1 seems to be setting a field named match (to a value of type Matcher) which could lead to memory leaks or other issues.
Did you forget the `def` keyword? Script1 seems to be setting a field named match (to a value of type Matcher) which could lead to memory leaks or other issues.
Did you forget the `def` keyword? Script1 seems to be setting a field named match (to a value of type Matcher) which could lead to memory leaks or other issues.
Did you forget the `def` keyword? Script1 seems to be setting a field named match (to a value of type Matcher) which could lead to memory leaks or other issues.
We haven't had the opportunity to address all of the issues yet. This work should be broken into smaller, manageable chunks, starting with minimal changes and thorough testing to ensure stability.
Also, it appears that it has been rolled back on the internal Jenkins side, as we no longer see the warnings.
This issue may have been resolved by Sophia's PR #6407 (specifically the change to JenkinsfileBase that removed parseResultSumFromTaps())
I suspect this because that PR removed a match variable which was not defined ("def") prior to use.
That change went into the master branch, but did not merge into the 1.0.8 release branch (which is why the release runs are seeing the issue).
This issue is related to the Jenkins config. We can add a startup option for the Jenkins instance to turn off the warnings
JAVA_OPTS=-Dorg.jenkinsci.plugins.workflow.cps.LoggingInvoker.fieldSetWarning=false
For details, please refer to the internal issue.
We have turned off the warnings for OpenJ9 Jenkins.
This issue is related to the Jenkins config. We can add a startup option for the Jenkins instance to turn off the warnings
JAVA_OPTS=-Dorg.jenkinsci.plugins.workflow.cps.LoggingInvoker.fieldSetWarning=falseFor details, please refer to the internal issue.
We have turned off the warnings for OpenJ9 Jenkins.
Are the warnings not useful though?
It's good to address these issues, but in my view, they aren't very critical. Currently, lots of warnings could hide the real error.
To fix all of them may be a significant piece of work; if we want to fix them, we need to break them down into smaller, manageable parts. We should start with a small scope and ensure thorough testing to avoid introducing any unintended issues.
I only see this single warning, repeated many times for some reason:
Did you forget the `def` keyword? Script1 seems to be setting a field named match (to a value of type Matcher) which could lead to memory leaks or other issues.
If Sophia's change did fix this, would we not be better off leaving the warnings enabled?
Ideally we'd prevent the "def" issue from being introduced altogether. Noted in the retrospective here.