Hi milki milk, sorry for the very long delay... Currently trying to followup on all the stuff that accumulated...
On 03 Sep 2015, at 16:32, milki milk <nitesha...@gmail.com> wrote: > On Thursday, September 3, 2015 at 4:03:50 AM UTC-7, Guenther, Marc(AWF) wrote: > >> On 01 Sep 2015, at 05:02, milki milk <nites...@gmail.com> wrote: >> >> > Yup that answers my question. My "testing", I meant the project repo >> > triggers a Jenkins job. Since the jenkins.yml file configures a job, are >> > all project initial jobs essentially the same - read the yml, configure >> > the jobs, run the jobs? >> >> Yes, exactly. The generator runs in the time span, that we always had for >> our Quiet Period anyway, which is 15sec. >> > I see that Jenkins Job DSL has a queue command. Is this how you trigger jobs > or do you have a subsequent build step that triggers a job? At the moment we use the normal Jenkins mechanism (the Github Plugin) to trigger jobs through the web hooks, with the 15sec delay. This has several drawbacks: - when the generator takes more than the 15sec to finish, the old versions of the jobs will be started. - new jobs do not get triggered the first time, as they didn't exist when the web hook was triggered. We are thinking to use the queue command instead, and turn off the builtin Jenkins polling/triggering mechanism completely. > Queue doesn't seem to have any explicit support for parameters. Parameters would not be needed, the web hooks do not have them either. > When you create a new repo, what do you use to create the initial Job DSL job > for the repo? I'm thinking either have a single Job DSL that is responsible > for all initial jobs or having JJB manage those initial jobs. Well, there is nothing special about new repositories. If they don't have a jenkins.yml file, they are simply ignored. If they have one, the generator job (= parameterized seed job) will do it's thing and create the relevant jobs. >> > Additionally, do you see performance issues when all the jobs? I find that >> > jenkins slows down with lots of jobs because it likes to parse job history >> > and artifacts all the time and stuff everything into memory. >> >> I don't really like to say this, but we do a daily restart of Jenkins >> master. Otherwise it wouldn't survive the week. Otoh, this was on the old >> legacy instance, and we never re-evaluated this, so maybe situation has >> improved with newer Jenkins versions. But given your statement, I guess not? >> ;( >> > We haven't been able to evaluate this effectively because we are so afraid to > do restarts which means its hard to do plugin updates or jenkins version > updates. We also didn't like to do daily restarts because we pretty much have > long and short jobs running all the time all day and all night long. Restarts > of the master are disruptive and we can't do safe restarts because of the > long running jobs. Yeah, I miss TeamCity in that respect. You could restart the master when ever you wanted, and the slaves would continue building and simply reconnect once the master is back... We use Swarm Client Plugin in Jenkins, so here too the slaves reconnect automatically, but the builds are all aborted... > Thanks for answering all my questions! This is the first time I've seen this > much detail about successfully managing Jenkins and it sounds great. Thanks :) Marc -- 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/85E1827F-609B-4168-BDBD-564FA200DC4F%40ebay.com. For more options, visit https://groups.google.com/d/optout.
