update an environment variable inside a kubernetes manifest

[till]

I have a Kubernetes manifest (Deployment) that looks like this:

piVersion: apps/v1
kind: Deployment
metadata:
  name: ctr
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: ctr
    spec:
      containers:
      - name: ctr-app
        image: r.example.org/ctr:local
        ports:
        - containerPort: 8080
          name: web
        env:
        - name: "ANOTHER_VARIABLE"
          value: "r.example.org/app:v1.2.3"

I would like to use updatecli to adjust the value of ANOTHER_VARIABLE whenever I cut a new release. Anyone have any thoughts on if this can be accomplished already? Or is this generally a bad idea? :D

[dduportal]

Hi @till , it is do-able and it makes sense.

You might want to use the yaml kind of resource. Something like this:

# ... scm
# ...
# ... sources ...
target:
  updateDeploymentEnvVar:
    kind: yaml
    name: Update ANOTHER_VARIABLE env. var. in the Deployment manifest
    spec:
      file: ./path/to/deployment.yaml
      key: $.spec.template.spec.containers[0].env[0].value

[till]

@dduportal Thank you so much! I had totally overlooked yaml somehow. It works perfectly!

I guess, follow questions:

• I build a flow where I update multiple of these keys (when available), for the action, I open a pull_request, but it only mentions one of them (even though both got updated). Am I supposed to use multiple actions (e.g. 2 PRs) instead?
• Second question, I looked at the transformers for "quoting" the value. But there's nothing, I think — should I add prefix/suffix " instead?

[till]

I guess to answer this, my workflow failed when only one of them had chances. But I split them up and it seems to be working.

[olblak]

@till Another approach would be to use the yaml plugin with the yamlpath engine.

sources:
  default:
    kind: shell
    spec:
      command: echo "r.example.com/app:v2.0.0"

targets:
  solution-1:
    name: 'bump ANOTHER_VARIABLE to {{ source "default" }}'
    kind: yaml
    spec:
      engine: yamlpath
      file: /tmp/deployment.yaml
      key: "$.spec.template.spec.containers[*].env[?(@.name == 'ANOTHER_VARIABLE')].value"
    transformers:
      - addprefix: '"'
      - addsuffix: '"'

  solution-2:
    name: 'bump ANOTHER_VARIABLE to {{ source "default" }}'
    kind: yaml
    disablesourceinput: true
    spec:
      engine: yamlpath
      file: /tmp/deployment.yaml
      key: "$.spec.template.spec.containers[*].env[?(@.name == 'ANOTHER_VARIABLE')].value"
      value: '"{{ source "default" }}"'

solution 1 relies on transformers to add quotes while the second approach disable source input and use the templating syntax.
The yamlpath approach is more complex than @dduportal suggestion but it will be more robust over time as it will still work no matter how the env array is modified in your deployment file also it can be used to update multiple values in a yaml file like in the following example

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ctr 
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: ctr 
    spec:
      containers:
        - name: ctr-app
          image: r.example.org/ctr:local
          ports:
            - containerPort: 8080
              name: web 
          env:
            - name: "ANOTHER_VARIABLE"
              value: "\"r.example.com/app:v1.0.0\""
        - name: ctr-app2
          image: r.example.org/ctr:local
          ports:
            - containerPort: 8080
              name: web 
          env:
            - name: "ANOTHER_VARIABLE"
              value: "\"r.example.com/app:v1.2.0\""

[till]

@olblak Thank you so much! Yeah, the yamlpath looks more robust as the indexes change. I'll give it a go too!

[till]

@olblak @dduportal Thank you both! I am marking this accepted. This was very, very helpful!

[olblak]

I build a flow where I update multiple of these keys (when available), for the action, I open a pull_request, but it only mentions one of them (even though both got updated). Am I supposed to use multiple actions (e.g. 2 PRs) instead?

All the targets in a single Updatecli file will target the same pullrequest assuming they all have the scmid set to the same value than the action.
One commit will be created for each target

[till]

@olblak yeah, I got individual commits, but the PR description only mentioned one of them. That's why I was asking. :)

[olblak]

Normally they should all be mentioned, this sounds like a bug to me

For example this manifest contains four targets and the four of them are listed on this pullrequest #1941

[till]

@olblak is it possible that diff creates files to keep track of changes? Or maybe it was just a coincidence. It did work this time around.

[olblak]

Most of the time running updatecli diff will not create/modify files if does then it's probably a regression.
There is only an exception for the shell plugin because it allows you to run any command but you can use the env variable "DRY_RUN" like in this example
https://github.com/olblak/updatecli-policy-docusaurus/blob/main/policy/updatecli.d/docusaurus.yaml#L88