> i don't do a lot of CI
Then I think you'll find peace with just using ngit things.
Yet CI is much more than just for boring linters/formatters. Depending on what exactly you're building, on some projects you might want to run some checks in the background: security checks, unused dependencies, slow integration tests, etc.
For me, in cargo-limit in particular, it was important to ensure it builds on a combinatorial explosion of weirdest OS configurations, which I'll never manage to deploy and maintain myself. On one hand I hate that I depend on GH with this; on the other I'd be happy to use something FOSS but only if it's something that's actually ready to run things, something that includes all infra that's continuously maintained by somebody. Very few of us are interested in maintaining a thing like ready-to-use GH workflows solution, but I'm sure a lot would be interested in using and paying for this.
CI is especially important for collaborations, though; people and bots creating pull requests with who knows what—a little thing may dramatically ruin something, as it happened with Coldcard.
Those who make the pull requests in security-critical projects could pay for the CI compute they generate, so their PRs would not be reviewed until the paid pipeline passes. This would be an improvement towards malicious bot attacks some projects are currently experiencing.
{
"id":"902c5d72e4066e992d4d29e8dda45551bf5a86ad81df4351d9131104088440f7",
"pubkey":"efc2b6e59480f0e55cc87c69af06b6d1a11fa25e4ea95a439878c41799c53c19",
"created_at":1790174746,
"kind":9802,
"tags": [
[
"e",
"ed765c1d210ac1da69fc5f34f134f736ba12308f3dfac94817768be3bd0be606"
],
[
"p",
"efc2b6e59480f0e55cc87c69af06b6d1a11fa25e4ea95a439878c41799c53c19",
"",
"author"
],
[
"context",
"\u003e i don't do a lot of CI\n\nThen I think you'll find peace with just using ngit things.\n\nYet CI is much more than just for boring linters/formatters. Depending on what exactly you're building, on some projects you might want to run some checks in the background: security checks, unused dependencies, slow integration tests, etc.\n\nFor me, in cargo-limit in particular, it was important to ensure it builds on a combinatorial explosion of weirdest OS configurations, which I'll never manage to deploy and maintain myself. On one hand I hate that I depend on GH with this; on the other I'd be happy to use something FOSS but only if it's something that's actually ready to run things, something that includes all infra that's continuously maintained by somebody. Very few of us are interested in maintaining a thing like ready-to-use GH workflows solution, but I'm sure a lot would be interested in using and paying for this.\n\nCI is especially important for collaborations, though; people and bots creating pull requests with who knows what—a little thing may dramatically ruin something, as it happened with Coldcard.\n\nThose who make the pull requests in security-critical projects could pay for the CI compute they generate, so their PRs would not be reviewed until the paid pipeline passes. This would be an improvement towards malicious bot attacks some projects are currently experiencing."
],
[
"alt",
"Highlight"
],
[
"comment",
"#security"
],
[
"client",
"Ditto",
"31990:781a1527055f74c1f70230f10384609b34548f8ab6a0a6caa74025827f9fdae5:ditto"
]
],
"content":"Those who make the pull requests in security-critical projects could pay for the CI compute they generate, so their PRs would not be reviewed until the paid pipeline passes. This would be an improvement towards malicious bot attacks some projects are currently experiencing.",
"sig":"94b9373953f009ac33aa1b77f65c7568a5bd96ba97198254a3f0369663cb9f1852dba34e3d0bbb7ee0c70cb7bdc55d28309c5ac8c39052bb52f42c3b47902813"
}
