Haha confusing terminology for sure! Let me see if I can break it down more clearly. So this is the current ScheduleGateConfig definition:
``templateId|string<br>The template containing the dependency target|string<br>Target to wait forI’m thinking of changing it to something like the following:
``templateId|string<br>The template containing the dependency target|string<br>Target to wait for continueOnFail|bool<br> Whether to still run the scheduled job if the dependency fails useLatestChange|boolean<br>Whether to use the latest change for the scheduled job, or the same change as the dependency job.Then in ScheduleConfig, instead of having
``gate | [ScheduleGateConfig](#schedulegateconfig)<br>Gate allowing the schedule to triggerI would have
``gates | [ScheduleGateConfig](#schedulegateconfig)[]<br>Gates allowing the schedule to triggerso that we can have multiple gate dependencies.
So then in my example, we have job Z, which will have job A and job B as gates. Then in code logic, I’d do something like the following on the server when job Z is triggered by schedule:
- For each gate in gates, trigger those gate jobs (jobs A and B)
- Continue to check if gate jobs have all completed. If not, continue to sleep and wait for them to complete
- Once all jobs (A & B) are completed, check their outcomes, and compare each one to their gates respective continueOnFail parameter.
- If any gate job fails and their gate continueOnFail is set to False, we fail job Z. Otherwise we will trigger job Z.
- Check each gates useLatestChange. If any of them are true, we will trigger job Z on the latest change. Otherwise we will trigger it on the change the schedule originally triggered on.
Hopefully my explanation of potential changes makes more sense now 