On Friday, March 17, 2017 at 2:02:43 PM UTC, Daniel Beck wrote: > On 17.03.2017, at 11:40, Turbo Fredriksson <fran...@gmail.com > <javascript:>> wrote: > > > > And with _a lot_ of commits (at the moment), there's going to be a lot > of waiting... > > This doesn't cost notable resources if you do it right, i.e. outside node > blocks. >
Perhaps, but it's bound to be very confusing - X number of jobs seemingly "running". In our current phase of development, we have _at least_ ten commits a day. We work in sprints of two weeks. So the QA people will be one sprint behind. That means the timeout needs to be at least two weeks (plus one day, but preferably all through THEIR two weeks sprint). That means that when QA picks up, there will be 10 jobs * (10 [working] days + weekends) * 2 sprints (one for dev, one for QA). Which of those was the correct commit they where supposed to QA?! Finding the right one of all those "running" jobs, will be a nightmare! Not to mention it is going to be difficult to find out from all those 200+ running jobs to distinguish really stuck ones from the ones that's waiting for input. Not to mention the fact that I kill of all Jenkins executors automatically at night (to save us some money :) and spin up new, fresh ones in the morning (weekdays only). So those "running" jobs will "vanish" anyway. That being said, this is _MY_ "vision" on how I would like it to be. My vision might be blurred, so feel free to correct me or give me a better option.. -- 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/e9e512b9-8a71-44d3-854c-4973f5859943%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
