Say I have the two following workflows defined:
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?
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.
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:
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:
# `build` and `test` are run in parallel. See
In this case
deploy_staging will require
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:
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).
CCI’s Reusable Config Reference. Properly using parameterized jobs can get around a lot of reuse issues.