jenkins: # Fresh install. Dynamic Kubernetes build agents come from agent.enabled # (chart default, not overridden here) — agent pods only exist during # builds, matching claude.md's "idle cost is just the controller" note. # Trimmed agent pod resources below anyway, since they still compete for # the same 8GB box while a build is running. controller: image: # Chart's default (unset here) falls back to appVersion 2.504.2 — # but the chart's own bundled default plugin list (kubernetes, # credentials, workflow-*, git, etc.) requires Jenkins core # >= 2.504.3. Upstream inconsistency between the chart's pinned # image tag and its own default plugins.txt, not our config — # bumping the core image is the fix, not trimming plugins (several # of them, especially `kubernetes`, are what dynamic build agents # actually depend on). tag: "2.504.3-jdk21" # Chart default installPlugins list pins configuration-as-code at # 1971.vf9280461ea_89, but kubernetes/git/credentials — also in that # same default list — need 2006.v001a_2ca_6b_574. Another upstream # chart-defaults inconsistency, same category as the image tag one # above. Lists replace wholesale in Helm, not merge, so this is the # chart's full default list with just that one version corrected — # not a hand-picked subset. # # kubernetes-client-api added explicitly (not part of the chart's # default list) — kubernetes originally pinned at 4353.vb_47977da_9417 # required kubernetes-client-api >= 7.3.1-256.v788a_0b_787114 # (confirmed via https://plugins.jenkins.io/kubernetes/dependencies/), # but left unpinned it resolved to an older version at image-build # time, producing `NoSuchMethodError: # ConfigBuilder.withMasterUrl(String)` on every agent launch attempt # — pods provisioned fine but the controller crashed trying to # actually connect the agent (Reaper.preLaunch -> KubernetesCloud.connect # -> KubernetesFactoryAdapter.createClient), so builds hung forever at # "Still waiting to schedule task". kubernetes itself later bumped to # 4437.v3a_18554d3f32 (updated via the Jenkins UI, then pinned here # to match so a future restart doesn't silently revert it) — same # kubernetes-client-api floor, and this exact pairing is what got a # real build through checkout successfully. installPlugins: - kubernetes:4437.v3a_18554d3f32 - kubernetes-client-api:7.3.1-256.v788a_0b_787114 - workflow-aggregator:608.v67378e9d3db_1 - git:5.7.0 - configuration-as-code:2006.v001a_2ca_6b_574 # readYaml (loadConfig.groovy's config.yaml parsing) and any future # writeYaml/readJSON-type usage — not part of the chart's default # list at all, missing entirely rather than version-mismatched like # kubernetes-client-api above. - pipeline-utility-steps:3.810.va_7672d206740 resources: requests: cpu: 100m memory: 512Mi limits: cpu: 500m memory: 1Gi admin: # Vault-backed from the start (unlike gitea, which started as a # plain kubectl secret and got migrated later) — see # devops-infra-argo-config/secretstores/jenkins-admin-credentials.yaml # and vault kv path secret/jenkins/admin. existingSecret: jenkins-admin-credentials userKey: jenkins-admin-user passwordKey: jenkins-admin-password ingress: enabled: true hostName: "jenkins.192.168.1.7.nip.io" ingressClassName: contour # This chart's primary ingress only supports one hostName — no # extraHosts like argo-cd. secondaryingress renders a whole second # Ingress object at the same backend (confirmed against the actual # template, not assumed) — that's the supported way to get a second # hostname here. paths must be set explicitly: the template just # renders zero routes if left at the chart's own default `[]`, unlike # the primary ingress. secondaryingress: enabled: true hostName: "jenkins.100.90.248.118.nip.io" ingressClassName: contour paths: - / agent: resources: requests: cpu: 250m memory: 256Mi limits: cpu: 500m memory: 512Mi persistence: enabled: true storageClass: local-path size: 5Gi