Making a cloud CI/build/release system whose behavior can't be reproduced locally requires some kind of brain damage. I can't believe people tolerate this.

▲

emilburzo an hour ago | parent [-]

That's... not what I said at all?

But let's go with that scenario, now you have all sorts of problems, from practical to security, like:

- accidentally/maliciously building the wrong thing? there's a patch, people agreed to it, but the wrong commit is built

- building for multiple architectures/versions?

- signing keys on someone's laptop?

- worse, image push/write keys on someone's laptop?

And so on.

	▲	modeless an hour ago \| parent [-]
		The problems you describe in your first post are only problems when you can't reproduce your build process locally. With a local build you can always do it in private for free. The problems you bring up here are eminently solvable too. Yes there are many solutions for building for multiple architectures and versions. Cross builds, containers, VMs, or just having more than one computer locally. You can address building the wrong thing with reproducible builds, but for a one off patch like this it's not the most likely problem and relying on a trusted maintainer temporarily during an emergency is better than waiting for a glacially slow cloud build while exploits spread. Pushing builds to the cloud is inherently a cloud step, so it's fine to leave keys for that in the cloud, but there should be a process for publishing local builds and it should be essentially instant when the build is already done. You should always have a local build process that replicates CI. There is no excuse.