Skip to content

[JENKINS-76297] withEnv with '+=' adds new path to jnlp container's PATH, not to current containers PATH #533

@jenkins-infra-bot

Description

@jenkins-infra-bot

When I use withEnv() inside container() to add a new path to the PATH env variable, it's the default JNLP container's PATH variable that get's extended, not the one I selected via container().

 

container('jnlp'){ // switch to JNLP container
    sh('''
        echo original PATH in container \$POD_CONTAINER
        echo \$PATH
    ''')    
    withEnv([
        "PATH+=/myNewPath" // append /myNewPath to JNLP container's PATH
    ]) {
        sh('''
            echo new PATH in container \$POD_CONTAINER
            echo \$PATH
        ''')
    }
}

container('build'){ // switch to another container which is not JNLP
    sh('''
        echo original PATH in container \$POD_CONTAINER
        echo \$PATH
    ''')    
    withEnv([
        "PATH+=/myNewPath" // expected to append /myNewPath to current container's PATH
   // but actually appends /myNewPath to JNLP container's PATH

     ]) {
        sh('''
            echo new PATH in container \$POD_CONTAINER
            echo \$PATH
        ''')
    }
} 

 

results in

 

 

I was expecting that my new path be added to the current containers PATH since I switched to it using container() step.

 

I guess appending to the current container's PATH would require the withEnv() step to inspect those env variables in the current container first which maybe does not happen. However, apparently, the withEnv() step does inspect the env variables of the JNLP container or some process further upstream did inspect the env variables of the JNLP container upon start of node and passes them down to withEnv().

 

My team's current workaround for this is to manually inspect the relevant env variables in the current container and then pass them as a finite value to withEnv()

container('build'){
    String oldPath = sh(script: 'echo \$PATH', returnStdout: true).trim() // manually inspect PATH variable in current container
    String newPath = "/myNewPath:${oldPath}"      // and add new path

    withEnv([
"PATH=${newPath}" // don't use appending via +=
  // but directly set value via =
    ]) {
sh('''
    echo new PATH in container \$POD_CONTAINER
    echo \$PATH
''')
    }
}

Please confirm if my expectation on this is wrong or if this is a bug in the withEnv().


Originally reported by burkhard, imported from: withEnv with '+=' adds new path to jnlp container's PATH, not to current containers PATH
  • status: Open
  • priority: Minor
  • component(s): workflow-basic-steps-plugin
  • resolution: Unresolved
  • votes: 0
  • watchers: 1
  • imported: 20251215-220547
Raw content of original issue

When I use withEnv() inside container() to add a new path to the PATH env variable, it's the default JNLP container's PATH variable that get's extended, not the one I selected via container().

 

container('jnlp'){ // switch to JNLP container
    sh('''
        echo original PATH in container \$POD_CONTAINER
        echo \$PATH
    ''')    
    withEnv([
        "PATH+=/myNewPath" // append /myNewPath to JNLP container's PATH
    ]) {
        sh('''
            echo new PATH in container \$POD_CONTAINER
            echo \$PATH
        ''')
    }
}

container('build'){ // switch to another container which is not JNLP
    sh('''
        echo original PATH in container \$POD_CONTAINER
        echo \$PATH
    ''')    
    withEnv([
        "PATH+=/myNewPath" // expected to append /myNewPath to current container's PATH
                           // but actually appends /myNewPath to JNLP container's PATH

     ]) {
        sh('''
            echo new PATH in container \$POD_CONTAINER
            echo \$PATH
        ''')
    }
} 

 

results in

 

 

I was expecting that my new path be added to the current containers PATH since I switched to it using container() step.

 

I guess appending to the current container's PATH would require the withEnv() step to inspect those env variables in the current container first which maybe does not happen. However, apparently, the withEnv() step does inspect the env variables of the JNLP container or some process further upstream did inspect the env variables of the JNLP container upon start of node and passes them down to withEnv().

 

My team's current workaround for this is to manually inspect the relevant env variables in the current container and then pass them as a finite value to withEnv()

container('build'){
    String oldPath = sh(script: 'echo \$PATH', returnStdout: true).trim() // manually inspect PATH variable in current container
    String newPath = "/myNewPath:${oldPath}"                              // and add new path

    withEnv([
        "PATH=${newPath}" // don't use appending via +=
                          // but directly set value via =
    ]) {
        sh('''
            echo new PATH in container \$POD_CONTAINER
            echo \$PATH
        ''')
    }
}

Please confirm if my expectation on this is wrong or if this is a bug in the withEnv().

  • environment: Jenkins 2.528.1
1 attachment

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions