Hi Carsten (2022.09.23_05:01:05_+0000) > sure, that's a killer argument that I can't really argue against. But that > is not the point for me. > > For all these checks we already have existing infrastructure, running the > same also by a pipeline job isn't helping at all if it's not clear how to > handle the fallout (we already mostly have seen in other places too!).
Yeah, it's similar for me. I test build locally, my sbuild setup does most (but not all) of the same checks as gitlab CI. Then when I'm happy I push and upload. If there is any gitlab CI, it runs too late. And if it fails, I usually don't even bother to investigate, because I trust my local setup implicitly. Anything that's failing in gitlab CI is almost certain to be a failure specific to gitlab CI. I do see a value in having it enabled globally, for the team, though. 1. It can make the team packages friendlier to new contributor team members who don't have a setup like that. I would like to see our team act more like a team and have people contribute to packages that they don't regularly maintain. 2. Getting a test failure on a merge-request catches contributor mistakes early. I love having CI on incoming patches like that. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
