Caused by this PR: https://github.com/jenkinsci/jenkins/pull/7631

If you edit a job with multiple credential bindings of the same type (ex. "secret file", or "username and password (separated)"), this issue will cause all but one binding of each type to lose their credential selection unless you click the "Specific credentials" radio button on each one every time you edit the job.

Then the job will fail with an error like this until you edit the job to restore the credential selections:

java.lang.NullPointerException
	at java.base/java.util.Objects.requireNonNull(Objects.java:221)
	at com.cloudbees.plugins.credentials.CredentialsProvider.findCredentialById(CredentialsProvider.java:877)
	at com.cloudbees.plugins.credentials.CredentialsProvider.findCredentialById(CredentialsProvider.java:855)
	at org.jenkinsci.plugins.credentialsbinding.MultiBinding.getCredentials(MultiBinding.java:195)
	at org.jenkinsci.plugins.credentialsbinding.impl.UsernamePasswordMultiBinding.variables(UsernamePasswordMultiBinding.java:82)
	at org.jenkinsci.plugins.credentialsbinding.impl.SecretBuildWrapper.makeSensitiveBuildVariables(SecretBuildWrapper.java:126)
	at hudson.model.AbstractBuild.getSensitiveBuildVariables(AbstractBuild.java:1043)
	at org.jenkinsci.plugins.envinject.util.RunHelper.getSensitiveBuildVariables(RunHelper.java:55)
	at org.jenkinsci.plugins.envinject.service.EnvInjectActionSetter.addEnvVarsToRun(EnvInjectActionSetter.java:60)
	at org.jenkinsci.plugins.envinject.EnvInjectListener.loadEnvironmentVariablesNode(EnvInjectListener.java:81)
	at org.jenkinsci.plugins.envinject.EnvInjectListener.setUpEnvironment(EnvInjectListener.java:42)
	at hudson.model.AbstractBuild$AbstractBuildExecution.createLauncher(AbstractBuild.java:617)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:485)
	at hudson.model.Run.execute(Run.java:1900)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:44)
	at hudson.model.ResourceController.execute(ResourceController.java:101)
	at hudson.model.Executor.run(Executor.java:442) 

Hey benebsiny,

it appears your proposed change caused a regression for various users. Would you, or someone else of the commentors, be interested in submitting a PR to resolve this issue?
Otherwise, I will revert your PR and trade one issue in favor of another.

Hi, notmyfault. I'd like to. But it seems that there's another one being assigned this issue?

The assignment comes from choosing a plugin as a component. There's currently nobody working on it.

notmyfault I see. Sorry for mistaking the assignment. I'll try it.

Hi, tbeukhof . Could you provide the steps to reproduce this issue? I was unable to reproduce the example you provide.

I think the key is to have at least three (3) credential bindings in the job, because the issue doesn't seem to happen to the first and last bindings in the job (only the middle ones).

So steps to reproduce would be:

• Create a job
• Add at least three credential bindings to the job
• Save the job
• Edit the job
• View the credential bindings and note that the middle ones are missing some of the information

Thanks for providing those steps, Andrew.  I guess I assumed it was an issue with more than 1. I can reproduce the issue for the Invoke Gradle script repeatable sections with just 2 of them, though.

notmyfault I thought my PR could be reverted back since it seems lead to a bad circumstance. Maybe we could propose other solution to solve the original issue better.

I would argue that this is more than a minor priority, as it is preventing us from upgrading Jenkins beyond 2.390.

I have to agree with tbeukhof .  We also rolled back to a previous version of Jenkins to avoid running into this issue.

I went ahead and closed the PR I created to revert this behavior. The overall consensus is that using radios without an ID is considered a plugin issue and not supported by Jenkins itself. As already advised by drulli, this needs to be improved in the corresponding plugins, by adding and ID to their affected radios.

cc avenderov jprinet

I think I will go ahead and split this into 3 JIRAs, 1 per plugin. I will repurpose this one to be the Gradle plugin.

This Jira is now just for the Gradle plugin issue. JENKINS-70988 is for the Credentials Binding plugin issue, and JENKINS-70989 is for the File Operations plugin issue.

This is preventing us from upgrading beyond 2.391 of Jenkins.

The fix I proposed for JENKINS-70988 may solve the issue with Gradle as well.

I could not duplicate the problem in the current release using the gradle plugin.  It worked as expected in both the current release and with the fix from Jesse.

It would be very nice if one of those who can duplicate the issue on the current release would test the fix from Jesse to confirm that it resolves the issue. tbeukhof would you be willing to perform that test?

Yes, Jesse's change fixes this as well. Thank you!

Fixed by Jesse's change in JENKINS-70988. No change needed in the plugin. Closing as a duplicate

Confirmed: 2.400 fixes this for Gradle build steps.