Hi,
On 2022-02-26 21:10:57 -0600, Justin Pryzby wrote:
> I did git commit --amend --no-edit and repushed to github to trigger a new CI
> run, and it did this: https://github.com/justinpryzby/postgres/runs/5347878714
>
> This is in a branch with changes to doc. I wasn't intending it to skip
> building docs on this branch just because the same, changed docs were
> previously built.
But why not? If nothing in docs/ changes, there's little point? It'd probably
be good to check .cirrus.yml and docs/**, to make sure that .cirrus logic
changes rerun as well.
> Why wouldn't the docs be built following the same logic as the rest of the
> sources?
Tests have a certain rate of spurious failure, so rerunning them makes
sense. But what do we gain by rebuilding the docs? And especially, what do we
gain about uploading the docs e.g. in the postgres/postgres repo?
> If someone renames or removes an xref target, shouldn't CI fail on its next
> run for a patch which tries to reference it ?
Why wouldn't it?
> It would fail on the buildfarm, and I think one major use for the CI is to
> minimize the post-push cleanup cycles.
I personally see it more as access to a "mini buildfarm" before patches are
committable, but that's of course compatible.
> Are you sure about cfbot ? AIUI cirrus would see that docs didn't change
> relative to the previous run for branch: commitfest/NN/MMMM.
Not entirely sure, but it's what I remember observing when ammending commits
in a repo using changesInclues. If I were to build a feature like it I'd look
at the list of files of
git diff $(git merge-base last_green new_commit)..new_commit
or such. cfbot doesn't commit incrementally but replaces the prior commit, so
I suspect it'll always be viewn as new. But who knows, shouldn't be hard to
figure out.
Greetings,
Andres Freund
