That's a really insightful reply and I thank you for that. Yes, we're using SCM for our regular projects, but for these jobs we haven't thought about it actually, since the specifics are that we have many, but small jobs which are created/generated automatically... but it makes sense to pull those from a centralized location, like SCM or database if that's the case... I'll have to rethink a bit our approach, based on your comments.
Thanks again. On Thu, Feb 7, 2013 at 12:04 PM, Mandeville, Rob <rmandevi...@litle.com>wrote: > I know approximately less than nothing about Gradle, but here goes > anyways…**** > > ** ** > > You can certainly put slave nodes on the same machine as the Jenkins > server, and there can be good reasons to do so. Making a separate slave > lets you configure it differently than the master nodes, if needed. It > also runs as a separate process, so it can be run as a different user, > given a different environment, etc. Doing this depends on how you launch > the slave.**** > > ** ** > > If you want to run Gradle builds on another machine, you’re going to have > to have Gradle installed on that other machine. Whether you’re running it > via a Jenkins slave node or any other way doesn’t matter. Basically, a > slave node is an agent on some machine that can run commands. It isn’t If > you can’t do it from the command line, you probably can’t do it from a > Jenkins slave either.**** > > ** ** > > As far as projects go, you’re going to have to get your sources onto the > machine your slave is on. If I’m reading correctly, you put your Gradle > sources (like build.gradle) at an absolute location on the machine your > Jenkins server is on. This is probably not going to work. Normal > procedure in Jenkins is to start your build by checking out sources from a > source-control system, so that each build has its own copy. **** > > ** ** > > If you’re not using a source control system, I strongly suggest you start, > especially if you’re scaling up. I’m not going to go over benefits here, > but will note that many of them are open source. Many SCM systems have an > associated Jenkins plugin. With that, a job can poll for changes and grab > the latest sources for you, putting it in the current directory for the > slave node. If you aren’t running on a polling basis (my outfit, for > instance, does nightly builds), then you just make a build step that grabs > the sources from SCM before you try building it. However, you now have to > do all your builds from a relative directory rather than an absolute > directory; this is usually good, as it means that you can run more than one > on the same machine.**** > > ** ** > > In short, I suggest that you figure out how you would run the builds you > want on other machines by hand _*without*_ Jenkins in place, and then > determine from there how to use Jenkins to automate that process for you.* > *** > > ** ** > > --Rob**** > > ** ** > > *From:* jenkinsci-users@googlegroups.com [mailto: > jenkinsci-users@googlegroups.com] *On Behalf Of *Octavian Covalschi > *Sent:* Thursday, February 07, 2013 11:37 AM > *To:* jenkinsci-users@googlegroups.com > *Subject:* Master/Slave configuration questions**** > > ** ** > > Hello,**** > > ** ** > > We have a number of Java projects, Selenium tests and using gradle to > build/test everything. So far this works fine for us if it's on one > machine, but we're looking to increase the number of projects/jobs and > would like to be ready to scale. **** > > ** ** > > As a result I'm looking to setup a master + few slaves configuration, but > there are some things that I'm not sure about. My thought is that initial > setup to be on one machine, with multiple jenkins instances (master + > slaves).**** > > ** ** > > So here are my questions:**** > > ** ** > > 1. Does it make sense to have master and slaves on the same machine at all? > **** > > 2. If we're using gradle, do I have to install gradle on other machines > too?**** > > 3. What about actual projects? Do I have to sync them on slave servers? > Since right now, gradle **** > > plugin asks path to build.gradle file, which we're setting to the absolute > path. How does this work?**** > > ** ** > > Thank you in advance.**** > > -- > 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. > > **** > The information in this message is for the intended recipient(s) only > and may be the proprietary and/or confidential property of Litle & Co., > LLC, and thus protected from disclosure. If you are not the intended > recipient(s), or an employee or agent responsible for delivering this > message to the intended recipient, you are hereby notified that any use, > dissemination, distribution or copying of this communication is prohibited. > If you have received this communication in error, please notify Litle & Co. > immediately by replying to this message and then promptly deleting it and > your reply permanently from your computer. > > -- > 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.
