Submit Your Ideas

We want to hear from you - vote for the features and improvements you'd most like to see, or submit your own ideas if you don't find them already listed.

Reusable job definitions

In general I'm a fan of the split between workflows and jobs, jobs defines what to run, workflows the when and with what parameters. To cut down on the possibility of failures I try and use the exact same series of steps to do deployments between my environments, and simply change the context that is being passed to that job. Unfortunately because the job name is the identifier of what to run and the position in the workflow I can't actually reuse that job definition across multiple environments.

For example it's become basically a pattern in my repos to do:

workflows:
  version: 2
  test_build_deploy:
    jobs:
      - unittest:
          context: shared-infrastructure
          filters:
            tags:
              only:
                - "/^release\\/.*$/"

      - image:
          context: shared-infrastructure
          requires:
            - unittest
          filters:
            branches:
              only:
                - "master"
                - "/^feature\\/.*$/"
                - "/^hotfix\\/.*$/"
            tags:
              only:
                - "/^release\\/.*$/"

      - deploy_branch:
          context: staging-infrastructure
          requires:
            - image
          filters:
            branches:
              only:
                - "master"
                - "/^feature\\/.*$/"
                - "/^hotfix\\/.*$/"

      - deploy_tag:
          context: production-infrastructure
          requires:
            - image
          filters:
            branches:
              ignore:
                - "/.*/"
            tags:
              only:
                - "/^release\\/.*$/"

now there is absolutely no difference between the deploy_branch and deploy_tag jobs, but i can't collapse it into a single job. I really just want to say: run deploy but use different contexts in different situations. This gets even worse in places where we build different images for different environments, because the requires: takes the job name which has to be unique.

 

I'd like to suggest we make the workflow job name optionally different to the job's name. For example:

workflows:
  version: 2
  test_build_deploy:
    jobs:
      - image_staging:
          job: image
          context: staging-infrastructure
      - image_production: 
job: image
context: production-infrastructure
- deploy_staging:
job: deploy
context: staging-infrastructure
requires:
- image_staging
- deploy_production:
job: deploy
context: production-infrastructure
requires:
- image_production

(assume there are some filters: in there that makes that workflow make sense) 

For backwards compatible if you don't specify job: then it defaults to the current job key which is how it works today.

Now i can treat my job like a function that i'm passing arguments to depending on the situation. (we can then talk about adding things like environment: to the workflow job definition, which would be the equivalent of passing arguments that aren't in context)

     

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Jul 18 2018
  • Planned