Loss of the source code server that is backing a project is catastrophic in all but a very few cases. I am not willing to consider a plugin change that would make the loss of a source control server non-fatal. I would expect the number of failure modes to be very high and the value to the over 250 000 Jenkins installations to be relatively low.

Hi Mark,

Thanks for your reply.

I get your concern and I'd like to clarify a few points:

• we're not talking about irrecoverable loss here, more temporary unavailability. 
• I totally get that this is not the desired behaviour for most projects, but making this behaviour opt-in wouldn't break any existing workflow. Are you concerned this feature would be incorrectly used in the field?

Thanks,

Alex

The git plugin is already a complicated collection of code that balances different requirements against one another so that they don't break compatibility for the 250 000 installations that depend on it. Adding a mode that causes a small set of users to expect that absence of a git server will be ignored is adding many places where inconsistences and oddities will be discovered and reported as issues. I would expect issue reports like, "Thing 1 does not ignore errors, but thing 2 does ignore them".

I am unwilling to spend the time and energy to create that type of special case and then own its maintenance, bug reporting, and care. There is simply not enough benefit for the time I would be required to spend on it.

You're certainly welcome to create a private fork of the git plugin and apply that type of change to the private fork. That then places the full maintenance responsibility on you so that you can decide what should be done when you detect issues.

Hi Mark,

This makes sense, thanks for taking the time to discuss this.

Best,

Alex