v2.3.0

What's Changed

• feat(registry): add support to artifact registry by @joaomlopes in #75

Full Changelog: v2.2.0...v2.3.0

v2.2.0

What's Changed

• ci: migrate to orb tools to 12 by @EricRibeiro in #68
• feat(rollout-image): update field to be able to set the workload type by @joaomlopes in #67

Full Changelog: v2.1.0...v2.2.0

v2.1.0

What's Changed

• feat: add support for gcloud version on all jobs by @joaomlopes in #66
• chore: fix inaccessible orb version in readme badge by @novedevo in #54

New Contributors

• @joaomlopes made their first contribution in #66
• @novedevo made their first contribution in #54

Full Changelog: v2.0.0...v2.1.0

v2.0.0 - Orb Modernization, Auth Plugin and OIDC

What's Changed

Word separation in all commands and jobs parameters is now represented with _ instead of -.

This change is part of an effort to standardize parameter nomenclature. Platform parameters such as resource_class or no_output_timeout use an underscore; however, orb parameters use a dash. We will move forward with an underscore for all parameters to streamline orb usage and creation.

⚠️ This is a breaking change. Please update the following parameters to ensure your workflow will keep working:

• gcloud-service-key
• google-project-id
• google-compute-zone
• google-compute-region
• no-output-timeout
• node-pool
• additional-args
• dry-run
• dockerfile-dir
• dockerfile-name
• extra-build-args
• use-remote-docker
• remote-docker-version
• dry-run
• docker-context

Commands are decoupled from other orbs.

Commands now follow the single-responsibility principle. This ensures they are free of dependencies and opinions, giving more flexibility to users. To illustrate, the create-cluster command should create a cluster. But in the current implementation, it installs the CLI, authenticates the user and then creates the cluster. This behaviour introduces side effects in the command and doesn't leave a lot of margin for customization.

⚠️ This is a breaking change. If you are using commands, you will have to manually run all steps that preceded it. For example, in v1.4.0, the rollout_image command could be used like this:

orbs:
  gcp-gke: circleci/[email protected]

jobs:
  my-job:
    - gcp-gke/rollout-image:
        cluster: my_cluster
...

And it would install the CLI, authenticate with gcloud, install kubectl, configure kubectl to work with GKE and, finally, roll out the image.This gives no leeway for custom behaviour between these steps. You must write the command yourself if you require a custom authentication method, a different version of CLI, kubectl or anything else. But now, after the decoupling, you have this:

orbs:
  gcp-cli: circleci/[email protected]
  gcp-gke: circleci/[email protected]

jobs:
  my-job:
    - gcp-cli/setup:
        components: "gke-gcloud-auth-plugin kubectl"
        use_oidc: true
    - gcp-gke/update-kubeconfig-with-credentials:
        cluster: my_cluster
        use_gke_cloud_auth_plugin: true
    - gcp-gke/rollout-image:
        cluster: my_cluster

You can control all aspects of the roll-out process, including using OIDC instead of a service key. And if you don't need any of that, you can still use the jobs that ship with the orb to avoid creating your own.

The perform-login parameter no longer exists

Due to the decoupling mentioned above, this parameter became obsolete and was removed. All jobs inside this orb will log the user in. And no command will do the same.

⚠️ This is a breaking change. If you use the perform-login parameter you must remove it.

The publish-and-rollout-image job will use the latest remote docker by default

In v1.4.0, the orb defaults to 17.09.0-ce. Now, the latest available version will be used if no version is provided.

⚠️ This is a breaking change. If you rely on 17.09.0-ce for your workflow to work, you must specify it:

orbs:
  gcp-gke: circleci/[email protected]

workflows:
  my_workflow:
    jobs:
      - gcp-gke/publish-and-rollout-image:
          ...
          remote_docker_version: "17.09.0-ce"

kubectl can be configured with gke-gcloud-auth-plugin

If you need to update your kubectl configuration file with GKE cluster access credentials, you can now use the recently introduced gke-gcloud-auth-plugin. To do so using commands, you must first install the plugin and kubectl with the gcp-cli orb and then use the update-kubeconfig-with-credentials command:

orbs:
  gcp-cli: circleci/[email protected]
  gcp-gke: circleci/[email protected]

jobs:
  my-job:
    - gcp-cli/setup:
        components: "gke-gcloud-auth-plugin kubectl"
    - gcp-gke/update-kubeconfig-with-credentials:
        cluster: my_cluster
        use_gke_cloud_auth_plugin: true # this is true by default. I have it here for illustration's sake

No extra configuration is necessary if you are using the publish-and-rollout-image job. It will take care of installing the plugin and configuring kubectl for you:

orbs:
  gcp-gke: circleci/[email protected]

workflows:
  my_workflow:
    jobs:
      - gcp-gke/publish-and-rollout-image:
          ...

OIDC is now supported

With the release of gcp-cli v3.0.0 , it is now possible to authenticate with OIDC instead of a service key. This should be the preferred method of authentication since it's more secure. To use it, you must set use_oidc to true and have GOOGLE_PROJECT_NUMBER, OIDC_WIP_ID, OIDC_WIP_PROVIDER_ID, OIDC_SERVICE_ACCOUNT_EMAIL set in a context or project settings.

orbs:
  gcp-gke: circleci/[email protected]

workflows:
  my_workflow:
    jobs:
      - gcp-gke/create-cluster:
          cluster: my_cluster
          use_oidc: true
          context: gcp-oidc # context with aforementioned variables