Package: git-debpush Version: 13.12 Severity: wishlist Currently git-debpush has a bunch of checks, and options to --force override those checks.
I would like it to have a new check that helps the average user avoid tagging and uploading commits that did not pass the CI (typically Salsa CI). The logic could be something along the lines: 1. Read the git remote URL or d/control Vcs-Browse field to deduce what is the Salsa project page for the package (if any) - alternatively skip check if package isn't on Salsa 2. Fetch pipelines for the package with something that is equivalent to: curl --silent "https://salsa.debian.org/go-team/packages/golang-github-ziutek-telnet/-/pipelines.json?scope=all&page=1"; | jq '.pipelines[] | [.commit.short_id, .details.status.label]' [ "b7e77496", "pending" ] [ "1abf88e1", "passed" ] [ "1abf88e1", "passed" ] 3. Check if the current git HEAD (or if --branch was passed the HEAD there) commit ID is in the list of pipelines, and if it has state 'passed'. Alternatively skip rest of the check if the package does not have pipelines and does not appear to be using CI. 4. Succeed and continue with tagging and pushing or fail with useful error message depending on situation: a) commit was not pushed yet - please push and wait until CI signals all green b) commit was pushed but state 'pending' - please wait and try again c) commit was pushed but state 'failed' - show a link to pipeline and request user to investigate and make CI green before pushing, or re-run git-debpush --force=ci-failure to override I don't know, maybe we could even consider having a note field too so people can do something like `git-debpush --ignore-ci-reason="Autopkgtest cannot pass before this version is uploaded due to circular depenency"` which could be recorded in the git tag and then other people working on the same repository would have a chance to understand why another developer intentionally uploaded despite failing CI. Another idea to throw out: Maybe in some cases git-debpush might even just keep running if job state was 'pending' and poll the pipeline once every 3 minutes or so until it passed and then automatically proceed. What do you think, would this make sense? Or should the CI check be at some other level of the tag2upload pipeline? Having it in the git-debpush itself and allowing developers to override it would probably be the most flexible solution and give enough soft enforcement that most people would stop and think before uploading stuff that is known to be broken in CI.
