如何提取并复用CircleCI config.yml中的YAML配置公共部分？

Great question! Reusing configuration in CircleCI is key to keeping your config.yml clean and maintainable, especially when you have multiple similar jobs. Let’s break down two approaches you can take, building on the YAML anchors you’re already using.

1. Extend YAML Anchors for Shared Steps #

Since you’re already using YAML anchors for your defaults block, you can create additional anchors for the repeated steps across your jobs. This works for both CircleCI 2.0 and 2.1+.

Refactored Config with Step Anchors #

defaults: &defaults
  working_directory: ~/repo/appengine
  docker:
    - image: circleci/python
      version: 2

# Define an anchor for shared deploy preparation steps
base_deploy_steps: &base_deploy_steps
  - attach_workspace: at: ~/repo
  - checkout
  - run: *setup_secret
  - run: *enable_npm
  - run: *appengine_dep
  - run: *webview_dep
  - run: *apps_dep

jobs:
  deploy_uat:
    <<: *defaults
    steps:
      - <<: *base_deploy_steps  # Reuse the shared steps
      - run:
          name: Setup key file
          command: |
            mkdir ~/gcloud_keys
            echo ${GCLOUD_UAT_ENV_KEY} | base64 --decode --ignore-garbage > ${...}

  # Example of another similar job (e.g., production)
  deploy_prod:
    <<: *defaults
    steps:
      - <<: *base_deploy_steps  # Reuse the same shared steps
      - run:
          name: Setup key file
          command: |
            mkdir ~/gcloud_keys
            echo ${GCLOUD_PROD_ENV_KEY} | base64 --decode --ignore-garbage > ${...}

2. Use Custom Commands (CircleCI 2.1+) #

For better readability and flexibility (especially if you need parameterization), CircleCI 2.1+ supports custom commands. This is the recommended approach for more complex reuse cases.

Refactored Config with Custom Commands #

version: 2.1  # Required for custom commands

defaults: &defaults
  working_directory: ~/repo/appengine
  docker:
    - image: circleci/python
      version: 2

# Define reusable commands
commands:
  # Shared deploy preparation steps
  base_deploy_prep:
    steps:
      - attach_workspace: at: ~/repo
      - checkout
      - run: *setup_secret
      - run: *enable_npm
      - run: *appengine_dep
      - run: *webview_dep
      - run: *apps_dep

  # Parameterized command for setting up GCloud keys
  setup_gcloud_key:
    parameters:
      gcloud_env_key:
        type: string  # Define the parameter type
    steps:
      - run:
          name: Setup key file
          command: |
            mkdir ~/gcloud_keys
            echo << parameters.gcloud_env_key >> | base64 --decode --ignore-garbage > ${...}

jobs:
  deploy_uat:
    <<: *defaults
    steps:
      - base_deploy_prep  # Call the shared command
      - setup_gcloud_key:
          gcloud_env_key: ${GCLOUD_UAT_ENV_KEY}  # Pass the UAT-specific env var

  deploy_prod:
    <<: *defaults
    steps:
      - base_deploy_prep  # Reuse the same preparation command
      - setup_gcloud_key:
          gcloud_env_key: ${GCLOUD_PROD_ENV_KEY}  # Pass the production-specific env var

Key Benefits of This Approach #

• Less duplication: You only write shared steps once, reducing errors from copy-pasting.
• Easier maintenance: Update shared logic in one place, and all jobs using it will automatically get the change.
• Clearer structure: Custom commands make your job definitions more readable, as you can use descriptive names for groups of steps.

内容的提问来源于stack exchange，提问作者Anthony Kong