Jenkins and GitHub Enterprise "Forking"

[Eric Fontana]

I'm new to Jenkins, I have the GitHub plugin installed and its connected to our GitHub Enterprise.  I'm able to have it watch a Repo and build

upon an agreed upon schedule.

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?

Thanks.

[Dirk Heinrichs]

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: d...@recommind.com
Skype: dirk.heinrichs.recommind
www.recommind.com

[Eric Fontana]

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.

[Dirk Heinrichs]

Am 02.09.2015 um 15:20 schrieb Eric Fontana:

we want to have certain branches restricted to certain contributors,

which isn't supported by GHE.

Yep, lack of proper access control is a big problem of GH.

Bye...

[Luca Milanesio]

@Dirk, yes and that’s why lots of people / projects prefer to use Gerrit on top of GitHub (e.g. Eclipse foundation, Openstack, …).

Have you tried using GerritHub? You can have the branch-level access control + Jenkins integration for your continuous delivery pipeline.

HTH

Luca.

 

On 2 Sep 2015, at 06:54, Dirk Heinrichs <dirk.he...@recommind.com> wrote:

Am 02.09.2015 um 15:20 schrieb Eric Fontana:

we want to have certain branches restricted to certain contributors,

which isn't supported by GHE.

Yep, lack of proper access control is a big problem of GH.

Bye...

    Dirk

--
<Logo.gif>

Dirk Heinrichs, Senior Systems Engineer, Engineering Solutions
Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach
Tel: +49 2226 1596666 (Ansage) 1149
Email: d...@recommind.com
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 jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/55E6FFA5.8020805%40recommind.com.
For more options, visit https://groups.google.com/d/optout.

[Kanstantsin Shautsou]

Validate GH PRs, work in forks, when fork will be ready for merge - PR to target branch, wait verification/do review. Pretty simple and easy.

[Nigel Magnay]

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.​

 

[James Green]

This would require Jenkins and the SCM to share permissions, wouldn't it? For Jenkins to be configured to "follow forks" it needs permission to access any other user's repositories as they may be a fork of the originally monitored repository?

Doesn't Bamboo do this? Or did I misread this feature?

--

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-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAPYP83Q%3DJP73Ap0agMre6Wri-9jHbW9EiKCJtUTASi3GbP5yAw%40mail.gmail.com.