Run job within workflow conditionally

Build Environment
1

From my understanding the workflow, at the top level, can contain a true / false condition which is great. My question is: Is it possible to apply conditions to specific jobs inside the workflow. for example:

  • If production the following jobs are triggered on master branch
  • if development another set of jobs are triggered on development branch

They would be passed as pipline parameters and I would image look something like this.

parameters:
  run-production: 
    type: boolean
    default: false
...
workflows:
  version: 2
  node-android-ios:
    jobs:
      - node
      - android-prod:
          when: << pipeline.parameters.run-production >>
          requires:
            - node
          filters:
            branches:
              only: master
      - ios-prod:
          when: << pipeline.parameters.run-production >>
          requires:
            - node
          filters:
            branches:
              only: master
      - android-beta:
          unless: << pipeline.parameters.run-production >>
          requires:
            - node
          filters:
            branches:
              only: development
      - ios-beta:
          unless: << pipeline.parameters.run-production >>
          requires:
            - node
          filters:
            branches:
              only: development

Thanks in advance for the assist.

2 Likes
2

Hey :wave:.

Yes, and no, and yes!

The most correct answer I believe would be to say that there should likely be multiple workflows, each that would be configured in a way where you wouldn’t need to drill down any further than that. That should also reduce complexity.

You could orbify a job for instance and then call it twice, once in each workflow, with the set parameter for that workflow.

Take a look at this workflow example from the aws-sam-serverless orb.

workflows:
  test_and_deploy:
    jobs:
      - sam/deploy:
          name: deploy-staging
          stack-name: staging-stack
          template: ./path/to/template.yml
      - test_my_api:
          requires:
            - deploy-staging
      - sam/deploy:
          name: deploy-production
          requires:
            - test_my_api
          stack-name: production-stack
          template: ./path/to/template.yml

You can see here in a single workflow the sam/deploy job is called twice. (Side note, we are able to do that in the same workflow because each is provided a unique name parameter). The job is called twice but was supplied a different stack-name which in this case meant we only had to define deploy once, but were able to change the deploy location.

You can use “reusable config” and author parameterized jobs directly in your config.
example:

version: 2.1
jobs:
  sayhello: # defines a parameterized job
    description: A job that does very little other than demonstrate what a parameterized job looks like
    parameters:
      saywhat:
        description: "To whom shall we say hello?"
        default: "World"
        type: string
    machine: true
    steps:
      - run: echo "Hello << parameters.saywhat >>"
workflows:
  build:
    jobs:
      - sayhello: # invokes the parameterized job
          saywhat: Everyone

Or if this is a task you use across multiple projects, maybe consider authoring an orb.

Within a job itself, you can even execute different steps based on the boolean value of a parameter using the when step.

version: 2.1

jobs: # conditional steps may also be defined in `commands:`
  job_with_optional_custom_checkout:
    parameters:
      custom_checkout:
        type: string
        default: ""
    machine: true
    steps:
      - when:
          condition: <<parameters.custom_checkout>>
          steps:
            - run: echo "my custom checkout"
      - unless:
          condition: <<parameters.custom_checkout>>
          steps:
            - checkout
workflows:
  build-test-deploy:
    jobs:
      - job_with_optional_custom_checkout:
          custom_checkout: "any non-empty string is truthy"
      - job_with_optional_custom_checkout

So if you actually wanted to, you could drill down even deeper to accomplish more of what you had mentioned in your original post py passing parameters into your jobs and using the when steps.

Hope that was helpful! Let me know if we can clear anything up.

2 Likes
3

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.