I mentioned most/all of these ideas for cfbot at some point. I'm writing them
now so other people know about them and they're in once place.
- Keep the original patch series and commit messages, rather than squishing
them into a single commit with cfbot's own commit messages. Maybe append an
empty commit with cfbot's message, and include a parsable "base-branch: NNN"
commit hash. This supports some CI ideas like making HTML available for
patches touching doc/ (which needs to be relative to some other commit to show
only the changes rather than every *.html). And code coverage report for
changed files, which has the same requirement.
That *also* allows directly reviewing the original patch series with a branch
maintained by cfbot, preserving the patch set, with commit messages. See also:
https://www.postgresql.org/message-id/flat/CAKU4AWoU-P1zPS5hmiXpto6WGLOqk27VgCrxSKE2mgX%3DfypV6Q%40mail.gmail.com
Alternate idea: submit the patch to cirrus as a PR which makes the "base
branch" available to cirrus as an environment variable (note that PRs also
change a couple of other cirrus behaviors).
- I think cfbot already keeps track of historic CI build results (pass/fail
and link to cirrus). But I don't think cfbot exposes this yet. I know cirrus
can show history for a branch, but I can never find it, and their history is
limited. This would be like the buildfarm pages, ordered by time: one showing
all results, one showing all failures, and one showing all results for a given
patch. You could also consider retrieving the cirrus logs themselves, to allow
setting our own retention interval (we could ask cirrus if they'd want to allow
setting more aggressive expiration for logs/artifacts).
- HTML: sort by CF ID rather than alpha sort. Right now, commitfest entries
beginning with a capital letter sort first, which at least one person seems to
have discovered.
- HTML: add a "queued for CI" page showing the next patches to be submitted to
cirrus. These pages might allow queueing a re-run, too.
- HTML: show "target version" and "committer" (maybe committer name would be
shown in the existing list of names, but with another style applied). This helps
to distinguish between patches which someone optimistically said was RFC and a
patch which a committer intends to commit, which ought to be pretty visible so
it's not lost in the mailing list and a surprise to anyone.
- index on CF ID without CFNUM - reasons that you mentioned that I can't
remember (like maybe cirrus history and rebuilds at end of each CF).
