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. Ian. -- Ian Jackson <[email protected]> These opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
