Add PriorityClass, ArgoCD jenkins-ci token, and Harbor robot secretstores

extra-manifests/priorityclass-high-priority.yaml: cluster-side
PriorityClass backing the app chart's hardcoded priorityClassName.
secretstores/argocd-jenkins-ci-token.yaml: ExternalSecret for the
scoped ArgoCD account devops-lib's syncArgoApp stage authenticates
with.
secretstores/harbor-robot-dockerconfig.yaml: ExternalSecret building a
dockerconfigjson from the Harbor robot account for image pulls.
This commit is contained in:
Mukul Sharma
2026-09-02 01:29:39 +05:30
parent 944ba711e2
commit 27c0445074
3 changed files with 84 additions and 0 deletions
@@ -0,0 +1,13 @@
# devops-helm-charts' generic app chart (1.0.0, in templates/deployment.yaml)
# hardcodes `priorityClassName: high-priority` on every Deployment it
# renders — no values toggle, unconditional. No such PriorityClass exists
# on this cluster, and a Pod referencing a nonexistent one gets hard-
# rejected by the API server at admission, not soft-failed. Simplest fix:
# just create it, rather than fork the chart's own template.
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: high-priority
value: 1000
globalDefault: false
description: "For app workloads deployed via devops-helm-charts' generic chart, which hardcodes this class name."
+31
View File
@@ -0,0 +1,31 @@
# Token for the scoped jenkins-ci ArgoCD account (see
# argocd-admin-prd/custom-values.yaml's accounts.jenkins-ci) — lets Jenkins
# trigger a sync of demo-go-app as the pipeline's last step, matching
# devops-lib's real refresh_and_sync (argocd app sync --hard-refresh).
#
# Unlike every other credential in this repo, this one genuinely can't be
# generated declaratively — ArgoCD only issues account tokens via its own
# API/CLI, after the account already exists on a running instance. One-time
# setup, once argocd-admin-prd has synced with the account config above:
# kubectl -n argocd port-forward svc/argocd-admin-prd-argocd-server 8080:80 &
# argocd login localhost:8080 --insecure --username admin --password '<admin password>'
# TOKEN=$(argocd account generate-token --account jenkins-ci)
# kubectl -n vault exec -i vault-0 -- vault kv put secret/argocd/jenkins-ci token="$TOKEN"
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
name: argocd-jenkins-ci-token
namespace: jenkins
spec:
refreshInterval: 1h
secretStoreRef:
name: vault-backend
kind: ClusterSecretStore
target:
name: argocd-jenkins-ci-token
creationPolicy: Owner
data:
- secretKey: token
remoteRef:
key: argocd/jenkins-ci
property: token
@@ -0,0 +1,40 @@
# Docker registry credentials for Jenkins to push to Harbor, as a proper
# kubernetes.io/dockerconfigjson secret (not a plain Opaque one) so it can
# be mounted straight at ~/.docker/config.json in the build container —
# docker push/pull read that format natively, no explicit `docker login`
# step needed in the pipeline itself.
#
# Vault-backed, same pattern as everything else. Put the robot account's
# credentials in first (create it in the Harbor UI: your CI project ->
# Robot Accounts -> New Robot Account, scoped to push+pull on that one
# project — Harbor shows the secret once, copy it immediately):
# kubectl -n vault exec -i vault-0 -- vault kv put secret/harbor/jenkins-robot \
# username='robot$<project>+<robot-name>' \
# password='<the generated secret>'
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
name: harbor-robot-dockerconfig
namespace: jenkins
spec:
refreshInterval: 1h
secretStoreRef:
name: vault-backend
kind: ClusterSecretStore
target:
name: harbor-robot-dockerconfig
creationPolicy: Owner
template:
type: kubernetes.io/dockerconfigjson
data:
.dockerconfigjson: |
{"auths":{"harbor-core.harbor.svc.cluster.local":{"username":"{{ .username }}","password":"{{ .password }}","auth":"{{ printf "%s:%s" .username .password | b64enc }}"}}}
data:
- secretKey: username
remoteRef:
key: harbor/jenkins-robot
property: username
- secretKey: password
remoteRef:
key: harbor/jenkins-robot
property: password