Injecting credentials as interpolated strings doesn't seems to work. It seems like the value of environment variables is ****. When I exec into the pod, I see the environment variable is correctly set. Log output from jenkins redacts the value.

withCredentials([                                                 
  string(credentialsId: 'FOO', variable: 'FOO')
]) {
  def FOO = env.FOO            
  podTemplate(
	label: 'test',
	containers: [
		containerTemplate(
			name: 'nodejs',
			image: 'node:alpine',
			ttyEnabled: true,
			command: 'cat',
			args: ''
		)
	]
) {

        node('test') {                                        
          container('nodejs') {                                 
  
            stage('env test') {                                
              sh """
                export FOO="$FOO"
                echo \$FOO
              """
            }
          }
        }
      
    }
  }

pchampon, actually it is working, the credentials plugin forces the log to not actually display credentials, but instead display the ** as you are seeing.

This should be fixed with JENKINS-46278
https://github.com/jenkinsci/kubernetes-plugin/pull/204
https://github.com/jenkinsci/kubernetes-plugin/pull/205

and tests added in https://github.com/jenkinsci/kubernetes-plugin/blob/master/src/test/resources/org/csanchez/jenkins/plugins/kubernetes/pipeline/runWithEnvVarsFromContext.groovy

csanchez this issue still seems to be present in scripted pipelines when environment variables are defined inside the container step.

This scenario (the same you have in your testcase) works:

withEnv(['foo=1']) {
  container('container') {
    sh 'echo foo=$foo' // prints foo=1
  }
}

But this one doesn't:

container('container') {
  withEnv(['foo=1']) {
    sh 'echo foo=$foo' // prints foo=
  }
}

Which also causes problems when using e.g. sshagent, as the sh step cannot see the SSH_AUTH_SOCK environment variable:

container('container') {
  sshagent(['credential-id']) {
    sh 'ssh-add -l'
  }
}

sshagent is supposed to be working, there is a test IIRC and some issues opened about it

Not everything will be able to run inside container()

Please open another issue if you can provide details

I opened JENKINS-49370 for my problem.

> Not everything will be able to run inside container()

Honestly, I would expect every step that works inside a node step to work inside a container step too. Is it documented somewhere which steps are supposed to work and which are not?

not documented, but I can't really make sure that the 1000+ plugins will work as it uses a totally new way of executing things in the containers

I do think it would be worth making the core plugins work as well as possible with the plugin, otherwise it become's a huge hurdle migrating things to it. I've had to completely reorganize many Jenkinsfiles to use the plugin when it really could have just worked without that if this functionality was more complete. I agree this probably isn't the highest priority, but it would be nice if this could be fixed in one of the next few releases, I'm basically holding off on some upgrades because it would be a lot of work to make their use of withEnv work with kubernetes-plugin.

there have been several fixes in the last releases and master as people brought up PRs for things that were not working

1.3.2 seems to have solved the problems with `withEnv` being nested within `container() { ... }`.

Previously, in a declarative pipeline, the job would execute as node `{ container { withEnv { ... } } }`, so I had to redundantly use a nested `container {}` inside every `stages/steps {}` to actualize the environment variables inside.

Since updating the plugin earlier today, and seeing [the PR that was merged](https://github.com/jenkinsci/kubernetes-plugin/pull/291), I was able to remove that, and the environment variables are working as expected.