> > > Don't use forks, use branches. > > Forks are good to allow people to contribute w/o being members of a > projects (i.o.w. w/o granting them push permission). This is not the case > for GH Enterprise, where all your devs are members of your project, aren't > they? > > Access control to the repository isn't the only use-case.
Fork + Building / Validating at PR time is useful, but because the forks themselves are invisible to Jenkins, you loose any of the benefits it might be delivering until that point. For example: we have Jenkins set up that when a commit occurs, one of the things spat out is a docker image. QA then has an easy 1-line command where they can start testing the feature. But we need to maintain agility. We don't want to wait until it's 'finished' to start doing exploratory testing. So we want Jenkins to build on any branch, in any fork. We tried doing this with a branch-only model with gerr it - but this quickly becomes unmanageable (you're back to a centralised repository model -- who namespaces the branches?; who is allowed to rebase the patch series? How does >1 developer collaborate on a feature that may never be committed?). No doubt process can probably find answers to that, but I find the github UI / model a lot more palatable. I think what's needed is for something like the multi-branch plugin that also supports multi-fork. Best you can probably manage at the moment is to duplicate the projects. -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAPYP83Q%3DJP73Ap0agMre6Wri-9jHbW9EiKCJtUTASi3GbP5yAw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
