[Feature] Environment variables for commands / flags

[sc250024]

• I'm submitting a ...
  • bug report
  • feature request
  • support request => Please do not submit support request here, see note at the top of this template.

Description

I'd like for it to be possible for the Octopus CLI to have environment variables for all (or most) of the CLI flags to make it easier to change settings in a CI/CD pipeline.

Currently there is some support for CLI flags, namely the global ones:

• --apiKey => OCTOPUS_CLI_API_KEY
• --server => OCTOPUS_CLI_SERVER
• --user => OCTOPUS_CLI_USERNAME
• --pass => OCTOPUS_CLI_PASSWORD

What I'd like is for all / most of the commands and subsequent flags to have support. For example:

• octo push --package=somepackage => OCTOPUS_CLI_PUSH_PACKAGE=somepackage
• octo create-release --releaseNotes=release-notes.md => OCTOPUS_CLI_CREATE_RELEASE_RELEASE_NOTES=release-notes.md
• Etc.

Current Behavior

I'd like this feature because currently my team has very complicated octo commands in our CI pipelines. It would be very helpful if it was possible to set various settings using environment variables since it wouldn't require a code change.

It would also prevent us from having to write our own wrapper script to do the same.

[jbristowe]

Thanks for submitting this issue, @sc250024. We're curious to understand your requirements. For example, why not use variables -- instead of environment variables -- in your workflow? We believe that environment variables should be used for sensitive values.

[sc250024]

I think I explained the use case above, right? Instead of having to run octo push that's followed by a long chain of command-line flags, I'd like if our pipelines could simply run octo push, and the configuration of the CLI would be embedded in environment variables. That way, we don't have to change code if we want to tweak a setting.

In my example, octo push can remain in our pipeline configuration as is. The environment variables would change it's behavior.

For example, why not use variables -- instead of environment variables -- in your workflow?

I'm not sure what you mean by this exactly. I'm talking about having the ability for the CLI itself to read environment variables for its configuration.

We believe that environment variables should be used for sensitive values.

I sincerely hope that's not the case. If that's true, you've just torpedo'ed a litany of applications that are deployed onto Kubernetes, and use environment variables for their configuration as per the 12Factor standard => https://12factor.net/config

The twelve-factor app stores config in environment variables (often shortened to env vars or env). Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard.

Try running something like helm template aws/aws-vpc-cni, and see how much of the configuration is environment-variable based.

helm template aws/aws-vpc-cni

---
# Source: aws-vpc-cni/templates/daemonset.yaml
kind: DaemonSet
apiVersion: apps/v1
metadata:
  name: aws-node
  namespace: paige-services
  labels:
    app.kubernetes.io/name: aws-node
    helm.sh/chart: aws-vpc-cni-1.1.14
    app.kubernetes.io/instance: release-name
    k8s-app: aws-node
    app.kubernetes.io/version: "v1.10.2"
    app.kubernetes.io/managed-by: Helm
spec:
  updateStrategy:
    rollingUpdate:
      maxUnavailable: 10%
    type: RollingUpdate
  selector:
    matchLabels:
      app.kubernetes.io/name: aws-node
      app.kubernetes.io/instance: release-name
  template:
    metadata:
      labels:
        app.kubernetes.io/name: aws-node
        app.kubernetes.io/instance: release-name
        k8s-app: aws-node
    spec:
      priorityClassName: "system-node-critical"
      serviceAccountName: aws-node
      hostNetwork: true
      initContainers:
        - name: aws-vpc-cni-init
          image: "602401143452.dkr.ecr.us-west-2.amazonaws.com/amazon-k8s-cni-init:v1.10.2"
          env:
            - name: DISABLE_TCP_EARLY_DEMUX
              value: "false"
            - name: ENABLE_IPv6
              value: "false"
          securityContext:
            privileged: true
          volumeMounts:
            - mountPath: /host/opt/cni/bin
              name: cni-bin-dir
      terminationGracePeriodSeconds: 10
      tolerations:
        - operator: Exists
      securityContext: {}
      containers:
        - name: aws-node
          image: "602401143452.dkr.ecr.us-west-2.amazonaws.com/amazon-k8s-cni:v1.10.2"
          ports:
            - containerPort: 61678
              name: metrics
          livenessProbe:
            exec:
              command:
                - /app/grpc-health-probe
                - -addr=:50051
                - -connect-timeout=5s
                - -rpc-timeout=5s
            initialDelaySeconds: 60
            timeoutSeconds: 10
          readinessProbe:
            exec:
              command:
                - /app/grpc-health-probe
                - -addr=:50051
                - -connect-timeout=5s
                - -rpc-timeout=5s
            initialDelaySeconds: 1
            timeoutSeconds: 10
          env:
            - name: ADDITIONAL_ENI_TAGS
              value: "{}"
            - name: AWS_VPC_CNI_NODE_PORT_SUPPORT
              value: "true"
            - name: AWS_VPC_ENI_MTU
              value: "9001"
            - name: AWS_VPC_K8S_CNI_CONFIGURE_RPFILTER
              value: "false"
            - name: AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG
              value: "false"
            - name: AWS_VPC_K8S_CNI_EXTERNALSNAT
              value: "false"
            - name: AWS_VPC_K8S_CNI_LOGLEVEL
              value: "DEBUG"
            - name: AWS_VPC_K8S_CNI_LOG_FILE
              value: "/host/var/log/aws-routed-eni/ipamd.log"
            - name: AWS_VPC_K8S_CNI_RANDOMIZESNAT
              value: "prng"
            - name: AWS_VPC_K8S_CNI_VETHPREFIX
              value: "eni"
            - name: AWS_VPC_K8S_PLUGIN_LOG_FILE
              value: "/var/log/aws-routed-eni/plugin.log"
            - name: AWS_VPC_K8S_PLUGIN_LOG_LEVEL
              value: "DEBUG"
            - name: DISABLE_INTROSPECTION
              value: "false"
            - name: DISABLE_METRICS
              value: "false"
            - name: DISABLE_NETWORK_RESOURCE_PROVISIONING
              value: "false"
            - name: ENABLE_IPv4
              value: "true"
            - name: ENABLE_IPv6
              value: "false"
            - name: ENABLE_POD_ENI
              value: "false"
            - name: ENABLE_PREFIX_DELEGATION
              value: "false"
            - name: WARM_ENI_TARGET
              value: "1"
            - name: WARM_PREFIX_TARGET
              value: "1"
            - name: MY_NODE_NAME
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName
          resources:
            requests:
              cpu: 10m
          securityContext:
            capabilities:
              add:
                - NET_ADMIN
          volumeMounts:
            - mountPath: /host/opt/cni/bin
              name: cni-bin-dir
            - mountPath: /host/etc/cni/net.d
              name: cni-net-dir
            - mountPath: /host/var/log/aws-routed-eni
              name: log-dir
            - mountPath: /var/run/dockershim.sock
              name: dockershim
            - mountPath: /var/run/aws-node
              name: run-dir
            - mountPath: /run/xtables.lock
              name: xtables-lock
      volumes:
        - name: cni-bin-dir
          hostPath:
            path: /opt/cni/bin
        - name: cni-net-dir
          hostPath:
            path: /etc/cni/net.d
        - name: dockershim
          hostPath:
            path: /var/run/dockershim.sock
        - name: log-dir
          hostPath:
            path: /var/log/aws-routed-eni
            type: DirectoryOrCreate
        - name: run-dir
          hostPath:
            path: /var/run/aws-node
            type: DirectoryOrCreate
        - name: xtables-lock
          hostPath:
            path: /run/xtables.lock
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: kubernetes.io/os
                    operator: In
                    values:
                      - linux
                  - key: kubernetes.io/arch
                    operator: In
                    values:
                      - amd64
                      - arm64
                  - key: eks.amazonaws.com/compute-type
                    operator: NotIn
                    values:
                      - fargate

[borland]

From an administrative point of view, from the perspective of something like a Github Actions or Azure DevOps CI yaml build pipeline, there is little difference between this:

env:
   OCTOPUS_PROJECT: MyProject
   OCTOPUS_PUSH_FILES: *.zip
run: octo

and this.

run: octo push --files=*.zip

Changing either requires a modification to the pipeline yaml file and one does not seem particularly easier than the other.

If you are using a different CI system, perhaps one that allows altering of environment variables via a GUI, rather than in a file, and you would like to use this as a workaround for situations where people can alter the variables in the GUI but can't commit the CI script, have you tried using variable substitutions?
Most CI systems will have some syntax where an environment variable string value can be interpolated into a script; this would let you achieve your goal without requiring any changes to the octopus CLI, or custom script writing on your behalf.

Something perhaps like this?

// external GUI sets OCTO_CMDLINE environment variable to "push --files=*.zip"

run: octo ${OCTO_CMDLINE}

// CI system interpolates variable, giving us `octo push --files=*.zip`