Hacker News new | past | comments | ask | show | jobs | submit login

Slightly related, in everything I see that allows adding secrets or env vars as code, they seem to prefer a list of objects instead of a key value pair for these. Does anyone know why this is? I know in some cases you can add additional values, but this seems easily solved by dynamically determining what the value is.

I'd much rather write:

    env:
      key: value
instead of

    env:
      - name: key
        value: value



The reason they do that is because then you can do things like extract envvar values from secrets.


Pedantically, there's nothing stopping them from doing it the way CFN does it: dispatching on the value's type:

  env:
    AWS_REGION: us-east-1
    AWS_SECRET_ACCESS_KEY:
      valueFrom: ...
CFN even goes as far as having two ways to pull off that stunt, magic prefixes and objects

  Properties:
    ImageId: !Ref MyAwesomeAmi
    # or
    ImageId:
      Ref: MyAwesomeAmi
    # or cursed "{{resolve" syntax
    ImageId: !Join
      - ''
      - - '{{resolve:ssm:/aws/service/bottlerocket/aws-k8s-'
        - Ref: EksVersion
        - '/x86_64/latest/image_id}}'
    # which ends up being "ImageId: '{{resolve:ssm:/aws/service/bottlerocket/aws-k8s-1.31/x86_64/latest/image_id}}'" and then *that* gets replaced by the CFN service at provisioning time




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: