Deploy last built image only, without building

[kimtore]

OP: https://nav-it.slack.com/archives/C5KUST8N6/p1728993202519389

Shape: https://github.com/nais/system/tree/main/deploy/deploy-uten-image

tl;dr: given updates to nais.yaml, make it possible to deploy again with the image that was built last time?

[Starefossen]

And, a change that does not require the app to restart (like fqdn) should not create a new deployment replica set and restart the app.

[kimtore]

It won't if the podspec is identical, which it should be even with a new Application saved to the cluster.

[mortenlj]

Jeg syns den foreslåtte løsning 2 (splitte ut accesspolicy i egen CRD) ikke er hensiktsmessig.

Det er mange andre deler av specen som har tilsvarende effekt, og det blir en slippery slope hele veien fra én Application til at folk bare har en Deployment-by-another-name pluss en haug med relaterte CRD'er som utgjør en applikasjon.

Jeg tror løsning 1 er veien å gå her, og jeg tror også vi kan lene oss tungt på Kubernetes idempotens.
I sin enkleste form, så er det som trengs en måte å hente image fra en annen kilde enn der man i dag lager taggen, og så gjøre deploy steget på nytt med nye YAML-filer, men "gammel" image verdi.

For eksempel kunne vi laget en action som finner tak i siste image tag som var deployet ( 👈 dette er den vanskelige biten), og så mater man den inn i nais/deploy i steden for den verdien man får fra docker-build-push.

[kimtore]

Enig i at alternativ 2 kan komme til å bli en glatt bakke.

Når det kommer til alternativ 1 kan man jo se for seg en utvidelse til deploy API som lar deg f.eks hente ut en applikasjon fra clusteret, eller til og med patche en eksisterende versjon. Sistnevnte høres dog litt skummelt ut i mine ører i og med at man ikke har full kontroll på specen som deployes.

[Reasonable-Solutions]

Imho, Restarts is a natural part of living in k8s and we shouldn't care about that.

The nais-nix action avoids rebuilds by getting a cache hit and then it's all copying from the cache. e.g just changing the spec takes 3 min and if you need a new image you get say, 6 min, but this depends on the shape of the flake!

At some point, I talked about that maybe application specs are artefacts in their own right that reference an image (It's not my best idea ever but it is also not my worst idea ever). There's some technical hurdles here but that's a mechanism for "
just deploy a new spec, no build".

For the communicating previous docker images, one could image some sort of usage of cross-workflow artifact upload/download. (Nais nix action builds a spec and then downloads it before applying it, in the same workflow tho).
The official download artifact action has an "elevate priviliges and download an artifact from another run (https://github.com/actions/download-artifact#download-artifacts-from-other-workflow-runs-or-repositories)

However, that has you care about workflow ids so you'd also need a way of getting the id of the latest relevant run and now you'd probably be forced to do some api calls anyway.

Otherwise I lean towards alternative 1 and would like to repeat the very good point @mortenlj made about .dockerIgnore and nais.yaml: nais.yaml goes in dockerIgnore

[rtc11]

Fra mitt brukerperspektiv ville en nais-apply GHA funket best, hvor man refererer til et eksisterende image på GAR.

[tronghn]

Fra mitt brukerperspektiv ville en nais-apply GHA funket best, hvor man refererer til et eksisterende image på GAR.

Dette kan man vel allerede få til ved å kjøre dagens nais/deploy action og sette IMAGE variabelen selv. "Problemet" er å finne ut av hvilket image som skal inn i variabelen. I dette tilfellet så ønsker ikke brukeren å måtte forholde seg til det; de vil bare ha det samme som kjører i clusteret.

Vi kunne sett for oss en "patch"-option i nais/deploy actionet som tar inn hele spec-en, men ignorerer image feltet.

I deployd kan vi kjøre en PATCH mot Kubernetes slik at det kun er endrede felter som oppdateres (med unntak av image) i stedet for dagens UPDATE/PUT der vi overskriver hele ressursen.

[Kyrremann]

Med tanke på hvor mange som har dette behovet så tror jeg det holder at de bare lagrer image som en Github action variabel, og bare henter den når de trenger dette.

https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables#defining-configuration-variables-for-multiple-workflows

Finner ingen Actions som gjør dette (som har flere enn et par stjerner), så kanskje man kunne bygd en selv. Ellers er det bare 20 linjer med Javascript.

async function updateVariable({
  variableName,
  value,
  variableExists,
  repoOwner,
  repoName,
  octokit,
}) {
  if (variableExists) {
    await octokit.request(
      "PATCH /repos/{owner}/{repo}/actions/variables/{name}",
      {
        owner: repoOwner,
        repo: repoName,
        name: variableName,
        value: value,
      }
    );
  } else {
    await octokit.request("POST /repos/{owner}/{repo}/actions/variables", {
      owner: repoOwner,
      repo: repoName,
      name: variableName,
      value: value,
    });
  }
}```

[Kyrremann]

Fant også denne actionen som kanskje kunne gjort det samme som Javascripten ovenfor: https://github.com/octokit/request-action.

[jhrv]

Hvis vi skal gjøre noe her, støttes forslaget til Trong.

Slik jeg leser det blir det noe ala:

      - name: Deploy to NAIS
        uses: nais/deploy/actions/deploy@v2
        env:
          CLUSTER: <MY-CLUSTER> # Replace
          RESOURCE: .nais/app.yaml #, topic.yaml, statefulset.yaml, etc.
          REUSE_IMAGE: true # <- eller noe i denne duren

Som man da kan lage et eget workflow for ved behov som f.eks bare trigges ved endringer i .nais katalogen e.l. og da er helt uten docker-build-push etc.
Dette måtte da blitt spesialhåndtert i deploy-cli/hookd som @tronghn er inne på

[kimtore]

Synes ikke vi skal lene oss på GHA, det blir en dependency på en ny ekstern funksjon. Det er fullt mulig å få til dette ved å endre på nais deploy.

PATCH-metoden kan fungere, men jeg lener heller mot å kunne få hente ut eksisterende ressurser fra clusteret når man bruker deploy-klienten. Det har vært etterspurt tidligere. Da kan man dytte inn image-verdien (og andre verdier) basert på eksisterende ressurs(er).