vaultwarden y gitea pasan a ArgoCD

Los dos estaban en git sin ninguna Application que los gestionara: editar el
repo no desplegaba nada. De ahi que un pin de imagen de abril nunca llegara
al cluster y gitea se subiera solo de 1.25.5 a 1.27.0, y que vaultwarden se
parcheara con kubectl replace. A partir de ahora manda git.

Verificado en frio antes de adoptar: los 17 manifiestos coincidian campo a
campo con lo vivo, asi que la adopcion no revierte nada. Con
ServerSideApply/ServerSideDiff, igual que el kube-prometheus-stack: estos
objetos arrastran un last-applied viejo y el merge clasico intentaria borrar
lo que ese blob declaraba y git ya no; en un PVC eso es un campo inmutable y
el sync falla.

Limpieza que iba en el mismo paquete:

- Fuera la basura de export de 5 ficheros: last-applied-configuration, la
  revision del Deployment y las anotaciones que pone el provisionador en los
  PVC (bind-completed, selected-node...). Es lo que dejaba los recursos
  OutOfSync para siempre. Verificado que el resto del manifiesto no cambia.
- Fuera serviceaccount-default y kube-root-ca.crt de los dos: los crea k8s
  solo en cada namespace.
- RESCATADO configmap-gitea-runner-config: config del act_runner escrita a
  mano en abril, montada por el runner y que NO estaba en git. Reconstruir
  gitea desde el repo levantaba el runner sin configuracion.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

gitea/argocd-app.yaml

@@ -0,0 +1,41 @@
+# gitea pasa a ArgoCD el 2026-07-25.
+#
+# Hasta hoy este directorio estaba en git SIN ninguna Application que lo
+# gestionara: editar aquí no desplegaba nada y había que acordarse de hacer
+# kubectl apply. Asi se colo que gitea subiera solo de 1.25.5 a 1.27.0 con un
+# pin de abril en git que nunca llego al cluster.
+#
+# Adoptado en frio y verificado ANTES de darle auto-sync: git y cluster
+# coincidian campo a campo en los 17 manifiestos de vaultwarden+gitea, asi
+# que esto no revierte nada.
+#
+# ServerSideApply/ServerSideDiff igual que en el kube-prometheus-stack: estos
+# objetos los creo un kubectl apply a mano y arrastran un last-applied viejo.
+# Con el merge clasico ArgoCD borraria lo que ese blob declaraba y git ya no
+# (anotaciones del provisionador en los PVC, revision del Deployment), y en un
+# PVC eso es un campo inmutable = sync fallido. Asi solo toca lo que declara.
+apiVersion: argoproj.io/v1alpha1
+kind: Application
+metadata:
+  name: gitea
+  namespace: argocd
+  annotations:
+    notifications.argoproj.io/subscribe.on-sync-failed.telegram: "5138407666"
+    notifications.argoproj.io/subscribe.on-health-degraded.telegram: "5138407666"
+    argocd.argoproj.io/compare-options: ServerSideDiff=true
+spec:
+  project: default
+  source:
+    repoURL: https://git.chemavx.xyz/chemavx/k8s-manifests
+    targetRevision: HEAD
+    path: gitea
+  destination:
+    server: https://kubernetes.default.svc
+    namespace: gitea
+  syncPolicy:
+    automated:
+      prune: true
+      selfHeal: true
+    syncOptions:
+      - CreateNamespace=true
+      - ServerSideApply=true

gitea/configmap-gitea-runner-config.yaml

@@ -0,0 +1,15 @@
+# Config del act_runner. Estaba SOLO en el cluster desde el 2026-04-13:
+# escrita a mano, montada por deployment-gitea-runner.yaml y ausente de git.
+# Rescatada el 2026-07-25 al meter gitea bajo ArgoCD — sin esto, reconstruir
+# el namespace desde el repo levantaba el runner sin configuración.
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: gitea-runner-config
+  namespace: gitea
+data:
+  config.yaml: "log:\n  level: info\nrunner:\n  file: /data/.runner\n  capacity: 1\n\
+    \  insecure: true\n  fetch_timeout: 5s\n  fetch_interval: 2s\n  envs:\n    DOCKER_HOST:\
+    \ tcp://localhost:2375\n  labels:\n    - \"ubuntu-latest:docker://catthehacker/ubuntu:act-22.04\"\
+    \n    - \"ubuntu-22.04:docker://catthehacker/ubuntu:act-22.04\"\ncontainer:\n\
+    \  network: \"host\"\ncache:\n  enabled: false\n"

gitea/ingress-gitea.yaml

@@ -3,9 +3,6 @@ kind: Ingress
 metadata:
   annotations:
     cert-manager.io/cluster-issuer: letsencrypt-prod
-    kubectl.kubernetes.io/last-applied-configuration: '{"apiVersion":"networking.k8s.io/v1","kind":"Ingress","metadata":{"annotations":{"cert-manager.io/cluster-issuer":"letsencrypt-prod","traefik.ingress.kubernetes.io/router.entrypoints":"websecure"},"name":"gitea","namespace":"gitea"},"spec":{"ingressClassName":"traefik","rules":[{"host":"gitea.chemavx.xyz","http":{"paths":[{"backend":{"service":{"name":"gitea","port":{"number":3000}}},"path":"/","pathType":"Prefix"}]}}],"tls":[{"hosts":["gitea.chemavx.xyz"],"secretName":"gitea-tls"}]}}
-
-      '
     traefik.ingress.kubernetes.io/router.entrypoints: websecure
   name: gitea
   namespace: gitea

gitea/pvc-gitea-data-pvc.yaml

@@ -1,15 +1,6 @@
 apiVersion: v1
 kind: PersistentVolumeClaim
 metadata:
-  annotations:
-    kubectl.kubernetes.io/last-applied-configuration: '{"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{},"name":"gitea-data-pvc","namespace":"gitea"},"spec":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"20Gi"}},"storageClassName":"local-path"}}
-
-      '
-    pv.kubernetes.io/bind-completed: 'yes'
-    pv.kubernetes.io/bound-by-controller: 'yes'
-    volume.beta.kubernetes.io/storage-provisioner: rancher.io/local-path
-    volume.kubernetes.io/selected-node: chemavx-k8
-    volume.kubernetes.io/storage-provisioner: rancher.io/local-path
   name: gitea-data-pvc
   namespace: gitea
 spec:

vaultwarden/argocd-app.yaml

@@ -0,0 +1,45 @@
+# vaultwarden pasa a ArgoCD el 2026-07-25.
+#
+# Hasta hoy este directorio estaba en git SIN ninguna Application que lo
+# gestionara: editar aquí no desplegaba nada y había que acordarse de hacer
+# kubectl apply. Asi se colo que gitea subiera solo de 1.25.5 a 1.27.0 con un
+# pin de abril en git que nunca llego al cluster.
+#
+# Consecuencia para vaultwarden: las subidas de imagen YA NO se hacen con
+# kubectl replace (como el 1.35.4 -> 1.36.0 del 2026-07-03). Se edita
+# deployment-vaultwarden.yaml, commit y push, y ArgoCD lo aplica.
+#
+# Adoptado en frio y verificado ANTES de darle auto-sync: git y cluster
+# coincidian campo a campo en los 17 manifiestos de vaultwarden+gitea, asi
+# que esto no revierte nada.
+#
+# ServerSideApply/ServerSideDiff igual que en el kube-prometheus-stack: estos
+# objetos los creo un kubectl apply a mano y arrastran un last-applied viejo.
+# Con el merge clasico ArgoCD borraria lo que ese blob declaraba y git ya no
+# (anotaciones del provisionador en los PVC, revision del Deployment), y en un
+# PVC eso es un campo inmutable = sync fallido. Asi solo toca lo que declara.
+apiVersion: argoproj.io/v1alpha1
+kind: Application
+metadata:
+  name: vaultwarden
+  namespace: argocd
+  annotations:
+    notifications.argoproj.io/subscribe.on-sync-failed.telegram: "5138407666"
+    notifications.argoproj.io/subscribe.on-health-degraded.telegram: "5138407666"
+    argocd.argoproj.io/compare-options: ServerSideDiff=true
+spec:
+  project: default
+  source:
+    repoURL: https://git.chemavx.xyz/chemavx/k8s-manifests
+    targetRevision: HEAD
+    path: vaultwarden
+  destination:
+    server: https://kubernetes.default.svc
+    namespace: vaultwarden
+  syncPolicy:
+    automated:
+      prune: true
+      selfHeal: true
+    syncOptions:
+      - CreateNamespace=true
+      - ServerSideApply=true

vaultwarden/deployment-vaultwarden.yaml

@@ -1,11 +1,6 @@
 apiVersion: apps/v1
 kind: Deployment
 metadata:
-  annotations:
-    deployment.kubernetes.io/revision: '2'
-    kubectl.kubernetes.io/last-applied-configuration: '{"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"name":"vaultwarden","namespace":"vaultwarden"},"spec":{"replicas":1,"selector":{"matchLabels":{"app":"vaultwarden"}},"template":{"metadata":{"labels":{"app":"vaultwarden"}},"spec":{"containers":[{"env":[{"name":"LOG_LEVEL","value":"warn"},{"name":"WEBSOCKET_ENABLED","value":"true"}],"envFrom":[{"secretRef":{"name":"vaultwarden-secret"}}],"image":"vaultwarden/server:latest","name":"vaultwarden","ports":[{"containerPort":80}],"resources":{"limits":{"cpu":"200m","memory":"256Mi"},"requests":{"cpu":"25m","memory":"64Mi"}},"volumeMounts":[{"mountPath":"/data","name":"data"}]}],"volumes":[{"name":"data","persistentVolumeClaim":{"claimName":"vaultwarden-pvc"}}]}}}}
-
-      '
   name: vaultwarden
   namespace: vaultwarden
 spec:

vaultwarden/ingress-vaultwarden.yaml

@@ -3,9 +3,6 @@ kind: Ingress
 metadata:
   annotations:
     cert-manager.io/cluster-issuer: letsencrypt-prod
-    kubectl.kubernetes.io/last-applied-configuration: '{"apiVersion":"networking.k8s.io/v1","kind":"Ingress","metadata":{"annotations":{"cert-manager.io/cluster-issuer":"letsencrypt-prod","traefik.ingress.kubernetes.io/router.entrypoints":"websecure"},"name":"vaultwarden","namespace":"vaultwarden"},"spec":{"ingressClassName":"traefik","rules":[{"host":"vaultwarden.chemavx.xyz","http":{"paths":[{"backend":{"service":{"name":"vaultwarden","port":{"number":80}}},"path":"/","pathType":"Prefix"}]}}],"tls":[{"hosts":["vaultwarden.chemavx.xyz"],"secretName":"vaultwarden-tls"}]}}
-
-      '
     traefik.ingress.kubernetes.io/router.entrypoints: websecure
   name: vaultwarden
   namespace: vaultwarden

vaultwarden/pvc-vaultwarden-pvc.yaml

@@ -1,15 +1,6 @@
 apiVersion: v1
 kind: PersistentVolumeClaim
 metadata:
-  annotations:
-    kubectl.kubernetes.io/last-applied-configuration: '{"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{},"name":"vaultwarden-pvc","namespace":"vaultwarden"},"spec":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"5Gi"}},"storageClassName":"local-path"}}
-
-      '
-    pv.kubernetes.io/bind-completed: 'yes'
-    pv.kubernetes.io/bound-by-controller: 'yes'
-    volume.beta.kubernetes.io/storage-provisioner: rancher.io/local-path
-    volume.kubernetes.io/selected-node: chemavx-k8
-    volume.kubernetes.io/storage-provisioner: rancher.io/local-path
   name: vaultwarden-pvc
   namespace: vaultwarden
 spec: