Informasjonsforvaltning / Informasjonsforvaltning/workflows

Bruk server-side apply i deploy-workflowene

Open
#282 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
0
Forks
2
Avg merge
5d 14h
Merged PRs (30d)
5

Description

## 🚀 Feature-forespørsel

### Feature-beskrivelse

Bytt fra client-side til `kubectl apply --server-side` i apply-stegene i de gjenbrukbare deploy-workflowene.

### Hvorfor trenger vi det?

Client-side apply beregner slettinger fra `last-applied-configuration`-annotasjonen. Et felt som aldri har ligget der — typisk lagt inn direkte mot klyngen — er usynlig for diffen og blir stående for godt, uansett hvor mange deployer som kjøres etterpå. Ingenting rapporterer avviket.

Det har skjedd: en env-variabel ble lagt inn manuelt på `service-catalog` i november 2025 og lå i den kjørende deploymenten i ni måneder uten å finnes i manifestet. CI-manifestet hadde 10 env-variabler, den kjørende hadde 11. Feltet var eid av field manager `kubectl`, ikke `kubectl-client-side-apply`. Den ble ryddet manuelt i september 2026.

Server-side apply sporer feltseierskap, så slike felter blir synlige og gir konflikt i stedet for å bli stående ubemerket.

### Berørte steg

| workflow | linje |
| --- | ---: |
| `kustomize-deploy.yaml` | 147 |
| `deploy.yaml` | 151 |
| `build-deploy.yaml` | 241 |
| `build-deploy-maven.yaml` | 273 |
| `build-deploy-nox.yaml` | 356 |

Fire av dem kjører `kubectl apply -f ./kubectlapply.yaml --force`. Med client-side apply betyr `--force` at ressursen slettes og opprettes på nytt ved konflikt, i stedet for at konflikten rapporteres. Dagens oppsett oppdager altså ikke drift, og ødelegger stille på de konfliktene det faktisk treffer. `--server-side` endrer denne kontrakten, så de to flaggene bør vurderes sammen.

### Forslag / løsning (valgfritt)

- Legg til `--server-side` og `--field-manager` med et fast navn i apply-steget.
- Vurder `--force-conflicts` for første kjøring: overgangen overtar eierskap fra den gamle annotasjonen, og vil da også avdekke eksisterende drift som konflikter.
- Erstatt `--force` med `--force-conflicts`, som er det som faktisk er ment her.

### Definisjon av ferdig

Apply-stegene bruker server-side apply med et navngitt field manager, `--force` er borte, og et felt lagt inn utenom manifestet gir synlig eierskap eller konflikt i stedet for å bli stående ubemerket.

Contributor guide

Open the contributing guide

Research direction

Inspect the apply steps at the listed lines in kustomize-deploy.yaml, deploy.yaml, build-deploy.yaml, build-deploy-maven.yaml, and build-deploy-nox.yaml. Compare their current --force usage and confirm the kubectl server-side apply options. Done means every apply step uses a named field manager, --force is absent, and out-of-manifest fields become visible ownership or conflicts.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions, kubernetes
Domain
ci-cd, devops, infrastructure
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.