Hello, On Thu 04 Sep 2025 at 04:49pm +01, Ian Jackson wrote:
> I've been thinking about this and I'm inclined to think the best way > to support the "fire and forget" user story with Salsa is: > > * The tag contains an instruction that CI should have passed, > and the identity of the forge. (Its domain name, I guess.) > > * The Manager uses Salsa's API and webhook system to determine > when CI has passed. The Manager passes the job to the Oracle > only when that is the case. The Oracle trusts the Manager on this > point. > > * If CI fails, Salsa will hopefully email someone. But the Manager > should also email the tagger. There should be at most one such > mail. CI failure is not fatal for the upload, though. If the CI > should pass later (eg someone hit "retry"), the upload will go > ahead. > > * If CI fails for cause and code update is needed, the user must burn > the version number and make a new changelog stanza. > > What I don't know is how git-debpush should know that it should put > this CI pass instruction in the tag. One option is to say that it > does that by default when the remote is salsa.d.o - so the default is > to require CI to pass if there is a pipeline. These ideas are very interesting. The last question, about git-debpush, does indeed seem unresolved here. For two complex packages I upload, sbcl and Emacs, the CI pipelines on salsa were set up by other people and always fail. I've never looked at them, leaving it to them. So such a default would very much get in my way. So ideally we can come up with something more subtle. -- Sean Whitton
signature.asc
Description: PGP signature
