Create rule S8319: GString interpolation syntax should match execution context requirements

rules/S8319/groovy/metadata.json

@@ -0,0 +1,29 @@
+{
+  "title": "GString interpolation syntax should match execution context requirements",
+  "type": "BUG",
+  "status": "ready",
+  "remediation": {
+    "func": "Constant/Issue",
+    "constantCost": "5 min"
+  },
+  "tags": [
+    "jenkins",
+    "groovy",
+    "interpolation"
+  ],
+  "defaultSeverity": "Blocker",
+  "ruleSpecification": "RSPEC-8319",
+  "sqKey": "S8319",
+  "scope": "All",
+  "defaultQualityProfiles": [
+    "Sonar way"
+  ],
+  "quickfix": "unknown",
+  "code": {
+    "impacts": {
+      "RELIABILITY": "BLOCKER",
+      "MAINTAINABILITY": "BLOCKER"
+    },
+    "attribute": "LOGICAL"
+  }
+}

rules/S8319/groovy/rule.adoc

@@ -0,0 +1,55 @@
+This is an issue when using closure syntax `${-> variable}` in Jenkins pipelines or expression syntax `${variable}` when lazy evaluation is needed in standard Groovy.
+
+== Why is this an issue?
+
+GString interpolation in Groovy supports two syntaxes with different evaluation behaviors. The expression syntax `${variable}` evaluates the variable immediately when the GString is created, capturing its current value. The closure syntax `${-> variable}` creates a closure that evaluates the variable each time the GString is used, providing lazy evaluation.
+
+In Jenkins pipelines, the Continuous Passing Style (CPS) transformation process cannot handle closures within GString interpolation. When Jenkins encounters `${-> variable}` syntax, it attempts to transform the closure for CPS compatibility, which results in runtime errors and pipeline failures.
+
+Conversely, in standard Groovy applications where you need the variable to be re-evaluated each time the GString is accessed (such as when the variable's value changes after GString creation), using expression syntax will capture only the initial value, leading to stale data and incorrect behavior.
+
+This context-dependent behavior makes it easy to choose the wrong syntax, especially when code is moved between different execution environments or when developers are not aware of the underlying evaluation differences.
+
+=== What is the potential impact?
+
+Using inappropriate GString interpolation syntax can cause runtime failures in Jenkins pipelines or produce incorrect results in standard Groovy applications. In Jenkins, closure syntax leads to CPS transformation errors that break pipeline execution. In standard Groovy, expression syntax can result in stale data when lazy evaluation is expected, causing logic errors and unexpected application behavior.
+
+== How to fix it in Jenkins
+
+In Jenkins pipeline contexts, use expression syntax instead of closure syntax to avoid CPS transformation errors.
+
+=== Code examples
+
+==== Noncompliant code example
+
+[source,groovy,diff-id=1,diff-type=noncompliant]
+----
+// In Jenkins pipeline context
+def status = "pending"
+def message = "Build status: ${-> status}" // Noncompliant
+status = "completed"
+println message
+----
+
+==== Compliant solution
+
+[source,groovy,diff-id=1,diff-type=compliant]
+----
+// In Jenkins pipeline context
+def status = "pending"
+def message = "Build status: ${status}"
+status = "completed"
+println message
+----
+
+== Resources
+
+=== Documentation
+
+ * Groovy Closures in GStrings - http://groovy-lang.org/closures.html#_closures_in_gstrings[Official Groovy documentation explaining closure syntax in GString interpolation and lazy evaluation]
+
+ * Jenkins Pipeline CPS Transformation - https://www.jenkins.io/doc/book/pipeline/cps-method-mismatches/[Jenkins documentation about CPS transformation and method compatibility issues]
+
+=== Related rules
+
+ * CodeNarc-ClosureInGString - https://codenarc.org/codenarc-rules-jenkins.html#closureingstring-rule[CodeNarc rule that flags closures in GString interpolation for Jenkins compatibility]

rules/S8319/metadata.json

@@ -0,0 +1,2 @@
+{
+}