This is reliably reproducible if one runs a multibranch pipeline with multiple branches building concurrently attempting to Grab via a globally configured pipeline library.

Here's an example: https://github.com/samrocketman/jenkins-bootstrap-jervis/issues/19

FWIW I consider this one to carry nontrivial risk of breaking libraries or triggering memory leaks or deadlocks... for now I'm going to wait to see if the Groovy community pulls in the fix and we can consume it downstream. 

Will leave the JIRA open for now in case someone from the community is bold enough to take this up and give it a try.  It's probably pretty simple to apply the change... but testing it and debugging might be a real challenge.

FTR - this is an issue I still regularly encounter.  I just regrettably tell my users that there's nothing I can do to fix it.   It's a core problem out of my control.

• Jenkins 2.235.1
  • Embedded Groovy 2.4.12
• workflow-cps plugin 2.86
• workflow-cps-global-lib 2.17

I have (unsuccessfully) tried adding @Grab to steps which can be retried on exception e.g.

retry(3) {
    grabDependencies()
} 

I've even considered sleep-based workarounds in shared pipeline library steps.  I haven't attempted a random-based sleep.

retry(3) {
    try {
        grabDependencies()
    } catch(Throwable e) {
        sleep(1)
        throw e
    }
}

However, users and I still  encounter "Error grabbing Grapes" issue within multibranch pipelines.  I've been silent because this report has been open but I figured I'd post an update since there hasn't been any activity on it.  I didn't want it to be assumed that this isn't an issue any longer.

Yes sag47 Yes

Jenkins Embarrassed me in this area also. 

A shared library with more than 50 functions (vars) is no useless until fixing this issue : 

The issue appeared previously, and i was able to fix it by : 

  customInitContainers:
   - name: setup-extra-configs
     imagePullPolicy: Always
     image: busybox:latest
     command:
     - sh
     - -c
     args:
     - ' echo ''Setting extra configmaps ..'' \
       && cp /tmp/extra-config/grapConfig_v2.xml /etc/groovy_home_dir/grapConfig.xml'
     volumeMounts:
     - mountPath: /tmp/extra-config/
       name: jenkins-extra-config
     - mountPath: /etc/groovy_home_dir
       name: jenkins-groovy-config

But now خلاص , we are done. we have to see alternatives

There has been no recent activity on the Groovy issue, and anyway picking up new Groovy releases in Jenkins is a hard problem and there is no concrete plan to do so. The general advice here is to just avoid Grape, and more broadly avoid doing tricky stuff in Pipeline script (whether in libraries or not). JENKINS-26635 is designed to make it as easy as possible to extract blocks of Groovy code from Pipeline script intact and move them to script files that can be run from external processes.

Any updates on this?

Can't use any generated Java API clients in my Groovy code, even tho a different library is included just fine, but when trying to migrate to a newer version, I do get the same error as mentioned above.

If the advice is "to just avoid Grape, and more broadly avoid doing tricky stuff in Pipeline script (whether in libraries or not)", then this is way more than just a "minor" issue. Things like this prevent us from using the Pipelines effectively. It should be said that while it's called "Groovy" in Jenkins, really this is no longer real Groovy...

We did have multiple problems with upgrading our external Java library.

First off, Jenkins caches those external Java libraries and thus you will not see that your grape config with your Artifactory/Maven Central, etc. credentials may already be outdated. Thus check your grapeConfig.xml (iirc) and its validity.

Second: When developing a wrapper around your e.g. Java Client library (that's generated from an OpenAPI Spec) You can use these annotations in order to prevent the caching and to always fetch a fresh artifact even tho the version might not have been changed.

@Grab( 
    group='cs.whatever', 
    module='cs-whatever-harbor-client', 
    version='2.0-SNAPSHOT', 
    changing=false 
) 
//changing=true can be used in order to update the cached Java library without the library having a new version

Setting changing=true will force Jenkins to always pull a fresh Java artifact/library from your repository.

In our shared library, we use various @Grab annotations. At times, when multiple pipeline jobs that use this shared library are run concurrently, we encounter the same ConcurrentModificationException problem that causes some jobs to fail at compile time.

A temporary solution we have found is to use the annotation

@GrabConfig(autoDownload=false)

alongside all @Grab annotations.  This solves the ConcurrentModificationExceptions we encounter, but has an additional requirement.  This will require that artifact/libraries specified via @Grab already be present on your jenkins servers when jobs are run. Artifacts/libraries can be downloaded onto your servers by using the grape cli tool.

To solve this requirement, we defined our dependencies in our global shared library, and then use a multibranch job that simply runs the grape cli command via a sh step in case there are any new dependencies or version changes for our master branch. This serves as a single point of entry for downloading artifacts, in essence eliminating concurrent modifications.

This can probably also be automated using configuration management or alternative solutions as well, but they key is using @GrabConfig and not modifying the grape cache concurrently.

I trace the code of Grab，and I found the grab logic is in  the dependency ivy，then I upgrade the ivy version. The problem dosen't appear thease days.

three_zhang what ivy version are you using? 

our jenkins info:

master: 2.387.2

ivy:2.4

still have this issue

we use @Library to load the shared library

Fixed in jenkinsci/pipeline-groovy-lib-plugin#148. Released in 749.v70084559234a_.