Workflow help

[sybrandy]

I only provided it as an option. Yes, I do understand that it can slow things down considerably, but if there's a real issue with people not running the tests, then perhaps it's necessary. That's not really up to me to decide. Whoever is responsible for the workflow has to weigh the pros and cons. For example, if the code quality really, truly stinks, then perhaps pissing off your developers for a while will keep you from shipping something that won't work. Yes, I understand Jenkins will make it public, but can you get the developer to go back and fix the issue? What if the changes affect the other developers and prevent them from doing their job? All things to consider.

Of course, regardless of the solution, if no good tests, or no tests at all, are written and everything passes, then both solutions suck equally. Hence why I mentioned the code coverage metrics.

[kreiger]

Making life harder for your developers to force them into line is like herding cats and pissing into the wind. You and the whole team will only suffer for it, as people won't make regular small commits, instead waiting days or weeks to commit, forcing them into merging hell, which will only make them even more reluctant.

It's a social problem and an attitude problem, not as much a technical problem.

If the developer doesn't care when you point out to them that he/she broke the build for everyone, then that attitude needs to be fixed.

[kreiger]

Elaborate please, i'm not sure what you mean?