shakedown tests to make sure everything is working,
instead of the comprehensive suite.
Any thoughts on that approach?
From: Christian Willman [mailto:cewi...@gmail.com]
Sent: Thursday, 6 March 2014 6:47 PM
To: jenkinsci-users@googlegroups.com
Cc: JOHNSTON, Rob
Subject: Re: Strategies to disk-risk a
To start, our jobs are 99% sameness. Most of our codebase can be built
using one standard job, running a well-defined list of Maven commands.
Realistically only the job name, SCM URL, and maybe timer or downstream job
list are variable. So the first step in mitigating risk is to group like
buil
I only update or add a plugin if it's needed by a user or fixes a bug
that's getting in the way. Since I'm driven by what users want I don't
restrict myself to LTS releases.
I run a parallel Jenkins setup with jobs that exercise each plugin we use,
and will only update the production system if al
Hi list
My group run a large Jenkins instance that many other teams in our organisation
depend on. We want to automate the Jenkins upgrade process which will include a
measure of verification that the upgrade hasn’t broken anything.
I’m thinking of only using LTS releases, backing up the main c
