Orb version

using aws-eks orb 0.2.2, which appears to use circleci/[email protected]. Posting this issue here since the aws-eks orb just passes the value down to the kubernetes orb untouched and it seems the kubernetes orb isn't supplying it to kubectl correctly.

What happened

Supplying a list of multiple images delimited by spaces fails to update multiple images. Instead, it attempts to set the first container's image to the entire string that comes after the first = character.

For instance, here's my circleci config.yml snippet:

          name: Staging Deploy
          requires:
            - Deploy to staging
          aws-region: us-east-2
          cluster-name: staging
          resource-name: deployment.v1.apps/my-app-staging
          container-image-updates: my-app=my-org/my-app:$CIRCLE_SHA1 my-app-job-runner=my-org/my-app:$CIRCLE_SHA1
          record: true

and here is the outcome:

Containers:
  my-app:
    Container ID:
    Image:          my-org/my-app:f3c65ebb0602966922eeceb92af37cdf6222d375 my-app-job-runner=my-org/my-app:f3c65ebb060296692
2eeceb92af37cdf6222d375

which of course leads to kubernetes image pull failures:

Warning  InspectFailed   10s (x5 over 26s)  kubelet, ip-192-168-9-21.us-east-2.compute.internal  Failed to apply default image tag "my-org/my-app:f3c65ebb0602966922eeceb92af37cdf6222d375 my-app-job-runner=my-org/my-app:f3c65ebb0602966922eeceb92af37cdf6222d375": couldn't parse image reference "my-org/my-app:f3c65ebb0602966922eeceb92af37cdf6222d375 my-app-job-runner=my-org/my-app:f3c65ebb0602966922eeceb92af37cdf6222d375": invalid reference format

I've tried wrapping the line in quotes or no quotes, but it doesn't seem to make any difference.

The other container retains its original image tag (i.e. is unchanged).

Expected behavior

I should have both containers updated with the new image tag.

This orb uses machine: true for an executor. We need to stop doing that.

My config.yml is really simple:

version: 2.1

orbs:
  kubernetes: circleci/[email protected]

workflows:
  version: 2
  ci_build:
    jobs:
      - deploy-image

jobs:
  deploy-image:
    docker:
      - image: 'cimg/base:stable'
    steps:
      - checkout
      - kubernetes/install-kubectl:
          kubectl-version: 1.14.8
      - run: kubectl version

But everytime it stops at run:

#!/bin/bash -eo pipefail
kubectl version
/usr/local/bin/kubectl: line 1: syntax error near unexpected token `<'
/usr/local/bin/kubectl: line 1: `<?xml version='1.0' encoding='UTF-8'?><Error><Code>NoSuchKey</Code><Message>The specified key does not exist.</Message><Details>No such object: kubernetes-release/release/1.14.8/bin/linux/amd64/kubectl</Details></Error>'

Exited with code exit status 2
CircleCI received exit code 2

I really don't understand what's the issue, please help, thanks.

Orb version

Latest version

What happened

Feature request. My K8S server is running on AWS (based on Kops)

Expected behavior

Support full featured kubectl commands, in order to achieve something like

  kubectl --namespace=${K8S_NAMESPACE} --server=${K8S_STAGING_MASTER} --token=${KS8_STAGING_TOKEN} --insecure-skip-tls-verify=true set image deployment/${K8S_DEPLOYMENT} ${IMAGE_NAME}=${REGISTRY}/${IMAGE_NAME}:${CIRCLE_SHA1}-staging

I think it would be great if parameters kubect-version and kops-version would pickup default from env vars KUBECTL_VERSION and KOPS_VERSION or something equivalent.

Orb version

0.3.0

What happened

Found a bunch of commands that were unclear purpose

Expected behavior

Expected to find a simple "update" or "deploy" orb example

more

Current example https://circleci.com/orbs/registry/orb/circleci/kubernetes#usage-deployment

1. we shouldnt need minukube to deploy, thats a testing use case right?
2. The deploy example should not delete resources
   3)we should be clear about the different intentions of apply, update, etc

circle ci version: 2.1, kubernetes: circleci/[email protected]:

What happened:

I get the error below when using kubernetes/update-container-image

--dry-run=false is deprecated (boolean value) and can be replaced with --dry-run=none.

Orb version

1.0.0

What happened

The install-kubeconfig section of the doc (and the source!) suggests KUBECONFIG as an env var to hold the base64 encoded kubernetes cluster config (also I need to look at the source to see that I need to base64 encode it). This causes all subsequent kubectl commands to fail as kubectl uses the same env variable to store the path to the config file - which is now a base64 encoded blob.

Expected behavior

The doc should suggest a different default name to hold the base64 encoded kubeconfig
The default for that variable should be different
The doc should state it needs to be base64 encoded

Orb version

0.3.0

What happened

Sometimes we just need to install kubectl without kops, the current command can't do that, because both of them are in 1 command.

Expected behavior

Separates into 2 commands, so when you only need kubectl, it can save execution time.

Orb version:

circleci/[email protected]

What happened:

Instead of install arm version, the orb install amd64 version on arm machine.

Expected behavior:

Install arm version.

Additional Information:

Seems like it's fixed in #68.

Orb version:

1.3.0

What happened:

Commands fail "install-kubectl" silently when invalid version has been specified:

Expected behavior:

Fail when invalid version has been provided like 1.22 instead of v1.22.8.

I think we can eg. check status code of response or use status-code sensitive tools to download. Alternatively we can try start kubectl & check version to fail early.

Additional Information:

Discovered in next step:

Orb version

0.11.0

What happened

I tried out the examples, e.g. https://github.com/CircleCI-Public/kubernetes-orb/blob/master/src/examples/deployment-update.yml

Expected behavior

Circle was reporting errors that an orb named kube-orb cannot be found.

Replacing occurences of kube-orb to kubernetes fixed the build.

If you want, I can provide a PR to fix the examples.

Orb version:

0.12.1

What happened:

While running a typical workflow (one that worked just hours previously), that uses kubernetes/install-kubectl, we hit

Flag --record has been deprecated, --record will be removed in the future
error: Invalid dry-run value (false). Must be "none", "server", or "client".

during kubernetes/update-container-image.

Snippet from the config.yml;

      - kubernetes/update-container-image:
          container-image-updates: "graphql-api=docker.io/org/repo:${CIRCLE_BRANCH}-${CIRCLE_SHA1}"
          get-rollout-status: true
          resource-name: deployment/graphql-apib

Looking at your source, you hit https://storage.googleapis.com/kubernetes-release/release/stable.txt to get the version of kubectl to install, and just today k8s pushed a new version, v1.23.0 (https://github.com/kubernetes/sig-release/tree/master/releases/release-1.23), that fully deprecates the "false" default you're using right now.

Expected behavior:

It should update the image using an appropriate default, in this case the string "none". You should also be locking the version of kubectl to a specific orb version, rather than blindly grabbing "latest" from a live text file.

Additional Information:

Copy of CircleCI-Public/aws-eks-orb#67 but posting here for visibility.

Orb version

aws-eks: circleci/[email protected]
kubernetes: circleci/[email protected]

What happened

We just started getting this error when running kubectl commands:

error: exec plugin: invalid apiVersion "client.authentication.k8s.io/v1alpha1"

  my-job:
    docker:
      - image: 'cimg/python:3.10'
    parameters:
      cluster-name:
        type: string
    steps:
      - kubernetes/install
      - aws-eks/update-kubeconfig-with-authenticator:
          cluster-name: << parameters.cluster-name >>
      - run:
          command: |
            kubectl version
          name: My Job

Expected behavior

The kubectl command should work, but instead its erroring on every command.

Describe Request:

kubectl rollout status, like apply will accept an -f flag identifying the resource.

We accept it for apply, but not status. And adding get-rollout-status: true should use the manifest we already passed to same orb command.

Examples:

Example pipelines generate the manifest in earlier steps. Since we are using Vamp release orchestration the deployment name is unique to each deployment, so to hardcode in config.yml is copy-pasta.

• Failed build because I didnt add resource name
  https://app.circleci.com/pipelines/github/eddiewebb/demo-blueskygreenbuilds/378/workflows/79e4c791-0859-46df-afcf-973264e7d845/jobs/2462
• passing build using kubectl rollout status -f instead
  https://app.circleci.com/pipelines/github/eddiewebb/demo-blueskygreenbuilds/379/workflows/de825702-5d27-4925-a2e1-da7a504ba8cc/jobs/2467

Supporting Documentation Links:

https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-status-em-

I use fx. $CIRCLE_PROJECT_REPONAME in deployment yml and substitute in an earlier custom run step before giving it to fx. kubernetes/create-or-update-resource. It would be nice if such substitution could be a simple opt in feature in this orb instead.

Orb version: 0.12.0

What happened:

During create-update-resource, there is an error in the script, which produces the error:

/bin/bash: line 10: [: missing `]'

Presumably this is preventing the server side apply parameter from working.

Expected behavior:

No error; server side apply parameter works.

Add git repo link to orb description.

Guideline:
https://github.com/CircleCI-Public/Orb-Policies/blame/master/Orb%20Best%20Practices%20Guidelines.md#L13

Describe Request:

Currently when one defines multiple resources using the same command exposed in the orb all of them have the same name which degrades readability. Adding new name parameter to the commands that would overwrite the default name used currently would improve readability of the pipeline run.

Examples:

steps:
  - kubernetes/create-or-update-resource:
    # no name specified, uses default value
    resource-file-path: resource1.yaml
  - kubernetes/create-or-update-resource:
    name: creating resource2
    resource-file-path: resource2.yaml
  - kubernetes/create-or-update-resource:
    name: creating resource3
    resource-file-path: resource3.yaml

Supporting Documentation Links:

https://circleci.com/developer/orbs/orb/circleci/kubernetes#commands-create-or-update-resource doesn't specify name parameter. In the source hardcoded value is visible.

Orb version

latest

What happened

There is no way to install a kubeconfig file using this orb.

Expected behavior

I would like to be able to set a base64 encoded environment variables containing my kubeconfig file.