J
Jamie Lennox
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)
CCI-I-506