Folder credentials silently removed after JCasC reload in Jenkins 2.541.x (worked in 2.528.3)

[pradhan567]

Jenkins and plugins versions report

Environment

• Jenkins: 2.541.1 / 2.541.2 (LTS)
• configuration-as-code: 2006.v001a_2ca_6b_574
• cloudbees-folder: 6.1053.vd62fb_b_f7367b_
• job-dsl: 1.84

Previously working with:

• Jenkins: 2.528.3
• cloudbees-folder: 6.1040.v8a_e6330a_54e3

Operating System

Linux (production Jenkins server)

Issue Description

After upgrading Jenkins from 2.528.3 to 2.541.x, manually added folder credentials are being silently removed during a JCasC reload. This was not the behavior in 2.528.3.

There is no warning or error in the logs — the credentials simply disappear.

What Operating System are you using (both controller, and any agents involved in the problem)?

Ubuntu

Reproduction steps

1. Start Jenkins 2.528.3 with a JCasC configuration that defines a folder with folderLibraries but does not define folderCredentialsProperty.

jobs:
  - script: >
      folder('test-folder'){
        properties {
          folderLibraries {
            libraries {
              libraryConfiguration {
                name("my-library")
                retriever {
                  modernSCM {
                    scm {
                      git {
                        remote("https://github.com/example/repo.git")
                        credentialsId("my-cred")
                      }
                    }
                  }
                }
              }
            }
          }
        }
      }

2. Manually add a credential to test-folder:

3. Navigate to: test-folder → Credentials → Folder → Add Credentials

4. Add a username/password credential with ID manual-cred

5. Trigger JCasC reload:
   Manage Jenkins → Configuration as Code → Reload existing configuration

6. On Jenkins 2.528.3
   Confirm that manual-cred is still present in test-folder

7. Upgrade Jenkins to 2.541.1 or 2.541.2

8. Repeat steps 2–3

9. On Jenkins 2.541.x
   Observe that manual-cred is removed

Expected Results

Expected Behavior
Folder credentials that are not defined in JCasC YAML should be preserved after a reload, consistent with behavior in Jenkins 2.528.3.
At minimum, a warning should be logged if folder properties are being overwritten or cleared.

Actual Results

Actual Behavior

• Jenkins 2.528.3: Manually added folder credentials are retained after JCasC reload
• Jenkins 2.541.1 / 2.541.2: Manually added folder credentials are silently removed after JCasC reload
  This represents a breaking change in behavior between these versions.

Anything else?

Impact

• Production incident caused by silent credential removal
• No warning or error logged
• Required rollback to 2.528.3 and restoration from backup
• Risk of data loss for folder-scoped credentials after upgrade

Are you interested in contributing a fix?

No response

[timja]

Do not duplicate issues in multiple places without cross-referencing at a minimum. (jenkinsci/configuration-as-code-plugin#2797)

If you can work out which version it changed in this will help narrow it down.

Note: Mixing JCasC and manually managed is never a great idea, it would be better and safer if you were to manage those folder credentials with JCasC / JobDSL.

[pradhan567]

We narrowed the behavior change to the following versions:

Component	Working	Broken
Jenkins Core	2.528.3	2.541.1 / 2.541.2
cloudbees-folder plugin	6.1040	6.1053
configuration-as-code	1998.v3e50e6e9d9d3	2006.v001a_2ca_6b_574
job-dsl	1.84	1.84

Concern

• This behavior change is not documented in the Jenkins 2.541.x upgrade guide.
• Folder credentials are removed silently without any warning or log message.
• This impacts existing deployments where folder credentials were created before adopting JCasC.

Questions

1. Can you confirm if this change from merge → replace behavior for folder properties is intentional?
2. If yes, could this be documented as a breaking change?
3. Could Jenkins log a warning when existing folder properties are overwritten?

[timja]

you would need to check between the weekly versions, between LTS lines isn't very useful.

its not intentional as far as I know but also not sure this was really a supported method of doing it. It may have worked but it was expected you would use jobdsl for this.

[debcodes076]

can i contribute to this issue?