Parameterized jobs within workflows?

workflow
cci-20

#1

Hi,

I’m upgrading to Circle 2.0 and find that I’m writing a lot of nearly identical deploy jobs with only a few environment variables changing between them.
I’d like to know if there’s a way to parameterize a job and launch it several times with different environment variables from a workflow.

What I’m trying to achieve is a system where all branches / tags get built and tested, but only the master branch gets deployed to staging, and after manual approval deployed to production. Also, feature branches with a specific git tag get deployed to a third testing environment.

In the workflow below, the deploy_* jobs are all identical except for some environment variables, and it would be great if I was able to write them once and run them several times with different parameters :

workflows:
  version: 2
  build-and-deploy:
    jobs:
      - checkout_and_modules
      - run_tests:
          requires:
            - checkout_and_modules
      - pack_and_build:
          requires:
            - run_tests
          filters:
            branches:
              only: master
      - gcloud_init
      - deploy_testing:
          requires:
            - gcloud_init
            - pack_and_build
          filters:
            tags:
              only: /^testing.*/
            branches:
              ignore: master
      - deploy_staging:
          requires:
            - gcloud_init
            - pack_and_build
          filters:
            branches:
              only: master
      - confirm_deploy_production:
          type: approval
          requires:
            - deploy_staging
          filters:
            branches:
              only: master
      - deploy_production:
          requires:
            - confirm_deploy_production
          filters:
            branches:
              only: master

#2

The best method of DRYing this up that I’ve considered is to include steps (and its array of steps underneath) into a reference you can include later.

Here’s an example of that sort of structure (not mine!):

You still have a lot of similar builds, but you can just vary the environment for each one instead of having a large duplicated set of build steps.


#3

@CJBridges, how do you use this with respect to .circleci/config.yml? This file is not generated and read on the fly by CircleCI. Do you just only ever work with the template, run the generator anytime changes have been made, and then commit and push those generated changes?


#4

If you just check the yml file only, these are out of the box features of YAML. There is no generation step, and no code is doing special case post-processing.

Here’s another example that may help increase clarity: https://github.com/integratedexperts/drupal-dev/blob/8.x/.circleci/config.yml

Look specifically at container_config and replace the keys underneath with steps instead.


#5