Remote polling executes on the central server. It does not require a copy of the source code on the central server, but it does require read access to the source code, since the "git ls-remote" command is used to perform the remote polling.
If you're unwilling to have the source code on your central server, you're probably also unwilling to have read access to the source code from the central server. I haven't tried using remote polling on a machine which is not the central server. I suspect that won't work. Jenkins does allow you to add credentials to the server and then use those credentials from within a job definition. I don't think there is a requirement that the Jenkins user generally needs read access to the git repository, just that the Jenkins process needs read access when using the credential you defined in Jenkins. Mark Waite On Thu, Dec 19, 2013 at 12:22 PM, David Gayman <qbd...@vt.edu> wrote: > Mark, correct I want no source code on the jenkins server. Currently I use > "Restrict where this project can be run" to force the build to be run from > one specific computer. Your logic would also work, the only issue being > that if the build is started one day on slave A and the next day on slave > B, a fresh clone of the repository must be performed at the top level > potentially for every build. Jenkins was designed to work this way, sharing > the load between many machines, which I'm sure is fine for small > repositories but is cumbersome for larger ones. > > Thank you for pointing out the remote polling option in the Git plugin > 2.0. I was using an earlier version and wasn't aware of this. That's > exactly the option I was looking for. > > ...Also are there security issues with this setup that I need to be aware > of? > > > On Mon, Dec 16, 2013 at 11:20 PM, Mark Waite <mark.earl.wa...@gmail.com>wrote: > >> I may have misunderstood your comment about not wanting to clone the >> source code onto the Jenkins server. If so, my apologies. I assumed you >> meant that you don't want the project source code to ever arrive on the >> central Jenkins server. >> >> One way to do that might be to constrain the jobs to never run on the >> master node (with "Restrict where this project can be run" set to >> "!master") >> >> Another technique might be to use remote polling. The central Jenkins >> server can poll for changes on the repository without having a complete >> copy of the repository if you are using Git plugin 2.0 (the current >> release), command line Git implementation (the default), and you do not >> require include regions or exclude regions. >> >> In the Git plugin 2.0, the option to require a cloned repo on the master >> server is listed as "Force polling using workspace". By default, the >> plugin uses "remote polling" instead of polling using a workspace. The >> remote polling does not require a local workspace on the master Jenkins >> server, but it does require that you are using the Git command line >> implementation (rather than JGit) and it requires that you are not using >> include regions, exclude users or exclude regions. >> >> Mark Waite >> >> >> On Mon, Dec 16, 2013 at 8:05 PM, David Gayman <qbd...@vt.edu> wrote: >> >>> Sure and I see how using a lot of small git repos, as opposed to one >>> large repo, could be beneficial. But for established code bases this is >>> often not the case. >>> >>> >>> On Mon, Dec 16, 2013 at 10:01 PM, David Gayman <qbd...@vt.edu> wrote: >>> >>>> Nice, I wasn't aware of shallow or reference clones. This could be >>>> helpful. >>>> >>>> One more note: The jenkins server is set up as a web server to the >>>> outside world. Our build machines are not exposed as servers. For security >>>> reasons no source code is allowed on the jenkins server; but it would be >>>> preferable to have this machine be in charge of running all builds. This >>>> makes sense to me from an organization standpoint, and the builds can be >>>> pretty resource-intensive so why not consolidate the build processes to run >>>> on the server. >>>> >>>> In this specific case, jenkins breaks. My server cannot both run all >>>> builds, and not clone the repository. (I work around this fine, it is just >>>> a convenience item for now, but doesn't make sense to me). >>>> >>>> >>>> >>>> On Mon, Dec 16, 2013 at 6:28 PM, teilo <teilo+goo...@teilo.net> wrote: >>>> >>>>> Sounds like you want a "shallow clone" rather than a full one. you >>>>> have thus option on the git plugin for about a year. >>>>> That way you won't have all of the history for the clone and hence >>>>> less disk space and network traffic is required. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to a topic in the >>>>> Google Groups "Jenkins Users" group. >>>>> To unsubscribe from this topic, visit >>>>> https://groups.google.com/d/topic/jenkinsci-users/IwgQSKqrC6g/unsubscribe >>>>> . >>>>> To unsubscribe from this group and all its topics, send an email to >>>>> jenkinsci-users+unsubscr...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>> >>>> >>>> >>> -- >>> 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. >>> >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Jenkins Users" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/jenkinsci-users/IwgQSKqrC6g/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> jenkinsci-users+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > 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. > For more options, visit https://groups.google.com/groups/opt_out. > -- 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. For more options, visit https://groups.google.com/groups/opt_out.
