config.xml 是 Jenkins 任务的唯一配置源，包含全部配置并实时读写；修改后需重载配置或重启才能生效，且不可明文存储敏感信息。
config.xml 是 Jenkins 任务的唯一配置源
Jenkins 任务（Job）的全部配置——包括构建触发器、构建步骤、环境变量、参数化选项、权限控制等——都序列化保存在对应任务工作目录下的 config.xml 文件里。它不是备份或快照，而是运行时唯一可信来源：Jenkins 启动时读取它加载任务，Web 界面修改后也立即写回它。删掉这个文件，任务就从 UI 上彻底消失（除非有 Job DSL 或 JCasC 覆盖）。
常见错误现象：java.io.IOException: Failed to load /var/jenkins_home/jobs/my-job/config.xml，通常是因为 XML 格式损坏（比如手动编辑时漏了闭合标签）、编码问题（含 BOM）、或被并发写入破坏（多处同时改同一任务）。
- 不要用文本编辑器直接在线编辑
config.xml，尤其不要在 Jenkins 运行时改——它可能正在读写 - 若需批量修改，优先用 Jenkins CLI 的
get-job/update-job，或通过 REST API 的POST /job/{name}/config.xml - Git 插件（如 Job DSL 或 Configuration as Code）生成的任务，其
config.xml会被覆盖，此时它只是“渲染结果”，不应手工维护
Jenkins 2.x 中 config.xml 的结构变化要点
Jenkins 1.x 和 2.x 的 config.xml 在核心字段上基本兼容，但关键差异在于插件扩展点和安全模型相关节点。例如，2.x 默认启用 useSecurity，且 authorizationStrategy 和 securityRealm 必须显式存在；而旧版可能为空或缺失。
使用场景：迁移老 Jenkins 实例时，直接拷贝 jobs/ 目录常导致新实例启动失败，报错类似 org.jvnet.hudson.reactor.ReactorException: java.lang.Error: java.lang.reflect.InvocationTargetException，根源常是 config.xml 里引用了已卸载插件的类名（如 hudson.plugins.git.GitSCM 写成 hudson.plugins.git.GitSCM2）。
- 检查
<scm class="xxx">、<builders><hudson.tasks.Shell>等 class 属性值是否与当前安装插件版本匹配 -
hudson.model.ParametersDefinitionProperty在参数化构建中必须存在，否则 Web 界面不显示参数输入框 - 2.300+ 版本开始，
projectNamingStrategy节点默认为hudson.model.ProjectNamingStrategy$DefaultProjectNamingStrategy，自定义命名策略需确保类路径可用
修改 config.xml 后 Jenkins 不生效？检查这三个地方
改完 config.xml 并重启 Jenkins，发现任务行为没变，大概率是缓存或加载机制没触发。Jenkins 不会轮询 config.xml 变更，只在启动、重载任务（Reload configuration from disk）、或调用特定 API 时解析。
常见错误现象：“改了 <quietPeriod>10</quietPeriod>，但构建还是立刻触发”——说明 Jenkins 没重新加载该任务配置。
- 进 Jenkins Web 界面 → 左侧菜单点击
Manage Jenkins→Reload configuration from disk（仅重载 job 配置，不重启进程） - 确认任务所在目录权限：Jenkins 进程用户（如
jenkins）必须对jobs/my-job/config.xml有读写权，否则 reload 会静默失败 - 检查 Jenkins 日志（
jenkins.log或 Web 界面的System Log），搜索Failed to load config.xml for my-job，比界面提示更早暴露 XML 解析错误
config.xml 里的敏感信息怎么处理
config.xml 明文存储密码（如 SVN 凭据 ID、SSH 私钥路径、环境变量值），这是 Jenkins 历史设计缺陷。它不加密，只靠文件系统权限隔离。一旦泄露，等于交出构建权限。
使用场景：把 jobs/ 目录纳入 Git 管理做版本控制，或导出任务给其他环境时，极易误传密钥。
- 永远不要把含
<password>、<privateKey>、<secret>的config.xml提交到代码仓库 - 用 Credentials Plugin 替代硬编码：将密码存为
Secret text或SSH Username with private key类型凭据，然后在config.xml中引用 ID，如<credentialsId>my-ssh-key-id</credentialsId> - CI/CD 流水线中，用
withCredentials步骤注入，而非从config.xml读取明文字段
config.xml 的解析是逐节点、弱校验的，有些字段写错只会让对应功能失效，不会中断启动；有些则直接导致任务不可见。最危险的是跨版本迁移时忽略插件兼容性声明，以及把凭据明文塞进可共享的配置文件里——这两处没 warning，但后果严重。 
