Well, they aren't. There are multiple groups, and we want to have certain branches restricted to certain contributors, which isn't supported by GHE. The fork model allows for this, which is why we are in this position in the first place.
If you want to ensure that master and develop are always in a "correct/good" state. On Wednesday, September 2, 2015 at 9:03:29 AM UTC-4, Dirk Heinrichs wrote: > > Am 02.09.2015 um 13:40 schrieb Eric Fontana: > > My question is, with GitHub's "Fork a Repo" flow, when a user forks a repo > (which was currently being tracked by Jenkins), it no longer > gets builds by Jenkins, since its a new repo now. If we want the forked > repo to get built upon commit/pushes whats the best way > to handle this? > > > 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? > > HTH... > > Dirk > -- > > *Dirk Heinrichs*, Senior Systems Engineer, Engineering Solutions > *Recommind GmbH*, Von-Liebig-Straße 1, 53359 Rheinbach > *Tel*: +49 2226 1596666 (Ansage) 1149 > *Email*: [email protected] <javascript:> > *Skype*: dirk.heinrichs.recommind > www.recommind.com > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/5a5c3d53-6042-43ce-bb4d-25be78913314%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
