On Wed, Apr 12, 2023 at 04:38:27PM +0200, Oskar Roesler wrote:
Am Mittwoch, 12. April 2023 15:58:58 CEST schrieb Knut Ahlers:
My personal 2 cents to on this topic:
All of my packages are maintained by CI and are auto-updating. I don't have the time (or to phrase it better: I'm not willing to invest the time) to do tasks, I can easily automate, manually. On the other hand all of my package-update-automations are patching the build and then executing it in a clean environment. If the package does not build the automation will break and notify me to have a look at what's broken.
In the end: What's the difference between a maintainer just modifying version and checksums and then pushing the broken package to AUR and an automation doing the same? Also: What's the difference between a maintainer patching version and checksums, executing a clean build and then pushing it and an automation doing the same? - Nothing.
So yeah, in my opinion maintainers (or automations) should at least do a clean build on update before pushing it. Putting up a policy against automations will just lead to maintainers still doing it in secret or to maintainers dropping a bunch of packages to orphan.
Full ack. When I maintained ~ 400 packages, the only way ship them was to have a CI building them in a clean environment and autopush them on successfull builds. Before I had this, packages were broken all the time. Clean build should be necessary before pushing any package, not just ones built by a CI.
Regards,
Oskar
"Autopush on successful builds" being the key here, imo. A lone misconfigured CI build that doesn't thoroughly test before pushing (or perhaps missing a test) shouldn't be grounds for banning any and all CI/CD here. I don't believe anyone is suggesting that CI/CD is completely disabled here, but the key topic of 'thoroughly testing, automatically' is probably the avenue to follow. I'd suggest that the package build in the original message simply gets another once-over to improve the robustness. -- Tom Swartz