Reference a job between workflows?

Build Environment
,
1

Hello.

Say I have the two following workflows defined:

workflows:
  build-and-test:
    jobs:
      - build-and-run-tests
  deploy-my-build:
    jobs:
      - deploy-to-staging:
          requires: 
            - build-and-test
        filters:
          branches:
            only:
              - staging

The required job for the deploy-to-staging exists in another workflow. Is it somehow possible reference this or do I need to have duplicate jobs specified with different filters for the same workflow?

1 Like
2

Hey @Repox! I’m pretty sure you can’t do this. Workflows operate independent of each other. If a job is dependent on another job, they should generally be in the same workflow.

3

Would referencing the job details via API work for you? We have a job endpoint in Preview where you can use the API in the other workflow - See:

https://circleci.com/docs/api/v2/#tag/Job

1 Like
4

It looks like you’re trying to build a simple deployment pipeline. Do I have that right?

If so, I think there’s no reason to have separate workflows at all? Assuming that you want to deploy to staging every time a commit is pushed to staging and you want to run all the jobs defined in build-and-test then just make it look like:

workflows:
  build-and-deploy:
    jobs:
      - build
      - test
      - lint:
          filters:
            branches:
              ignore:
                - staging
                - main
      # `build` and `test` are run in parallel. See
      # https://circleci.com/blog/introducing-workflows-on-circleci-2-0/
      - deploy:
          name: deploy_staging
          requires: 
            - build
            - test
          filters:
            branches:
              only: staging
          deploy_env: staging
      - deploy:
          name: deploy_production
          requires:
            - build
            - test
          filters:
            branches:
              only: main
          deploy_env: production

In this case deploy_production and deploy_staging will require build and test but will only run on their respective branch. When the branch doesn’t match then they simply won’t run (in fact they won’t even be shown in the workflow view).

The behavior here is fairly sophisticated and I would recommend setting up a throwaway branch and just experimenting with it. Probably the most surprising bit of behavior is that if a job in a workflow requires another job which is removed because it was filtered out for whatever reason that job will run (i.e. it the filter is fail → open by design). Once you get used to this behavior it’s actually fairly convenient.

Other things to be aware of:

  1. Anchors and Aliases in CCI’s YAML Guide. I use these judiciously. I think their best application is duplicating a workflow for commits and cron execution. I go back and forth on using them for ‘duplicated’ jobs (like the deploy_* jobs above).
  2. CCI’s Reusable Config Reference. Properly using parameterized jobs can get around a lot of reuse issues.

Good luck!

3 Likes