[falsedan]

Totally agree. When you have critical systems driven from Jenkins jobs, and they're called all hours of the day, how do you manage to upgrade Jenkins without trashing all the running jobs? (A: pay CloudBees for the Multi-Master plugin).

Jenkins skimps on so many basic problems (cleaning workspaces for deleted jobs, resource requirements for jobs, API which can handle 10 requests a second, config store that doesn't require parsing hundreds of XML files on startup). Plus it has its own git implementation, which has unconfigurable checkout behavior (i.e. fetch all branches then checkout), which makes it a huge disk hog on busy repos.

The plugin system is half-baked: we have to check every new plugin (& version) on a test instance to verify that it doesn't interact horribly with any existing plugin.

When Jenkins triggers a downstream job & blocks on it before continuing, it logs the job it triggered, but not the build (until after the job completes). This makes watching a build in progress extremely tedious, and you have to hunt through the builds of the triggered job to find the relevant build. None of this is exposed directly by the API, your client has to derive it itself.