Thought around https://github.com/jenkinsci/jenkins/pull/1172
When I think of the situation where build A's completion results in starting of build B, I think we need to support two notions:
1. A is configured to trigger B (somewhat like how you can publish your binaries to S3, for example) 2. B is configured to listen to the completion of A (much like how you can watch out for a change in SCM)
Both are legitimate and useful in different circumstances. #1 (push view) is useful for the same reason parameterized trigger is useful, or if you have a large number of upstream jobs feeding into downstream, say one job per personal branch. #2 (pull view) is useful other way around, say there's a common library that a lot of people depends on, or if A is owned by the engineering group and B is owned by the QA group.
I think our UI got it right in that sense, and I wonder if our failing is just that we internally normalize these configuration into the Recorder centric push view. Maybe we just need to start recording them separately.
Note that #1 and #2 above would need different permission checks. #1 would have to check if the principal running build A can see job B. #2 would have to check if the principal that will run build B can see job A.
I think of DependencyGraph as the cache of which project wants to know which project is finished. So I think it's still an useful data structure. Perhaps it'll just have to start to remember whether an edge is pull or push, and we'd let edge abstract away the access control check?
-- Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/ Try Jenkins Enterprise, our professional version of Jenkins -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
