Announcing Topic-Based CI

[Patrick Williams]

Greetings,

Up until now we've not been able to perform CI on dependent commits that
span repositories.  Generally you have to inform the maintainer(s) that
the commits are dependent and let them know that CI will fail until one
of the commits are merged.  Often, maintainers ignore commits that
have a "-1 Verified", so this can slow down the code review process.

In order to improve this situation I've written an enhancement[1] to our
CI that allows us to run CI on dependent commits, using Gerrit "topics".

Typically we run into this with phosphor-dbus-interfaces, but any
repository specified in the `build-unit-test-docker` can act as a
library / dependency for CI.  In order to get this to pass, upload the
PDI change to Gerrit first and add a "topic" (you can do this either
through the UI or by adding "%topic=foobar" to your `refs/for/branch`).
Then upload the depender change to Gerrit and add the same "topic".
Jenkins will then download the dependency when building the Docker
container to execute CI.

Caveats:
    1. To simplify the implementation, I only allow topic-based commit
       per repository.

       Suppose you have 3 commits to PLDM and 1 commit
       to PDI under the same topic.  This is fine because each PLDM
       commit will leverage the single PDI dependency and the PLDM
       commits will be tested individually (in git-order).

       Suppose you have 1 commit to PLDM and 3 commits to PDI.  This
       will not work unless the _last_ commit to PDI was the only one
       with the "topic" set.

    2. MAINTAINERS need to keep any eye out for this and confirm that
       all of the "topic" dependencies are ready for merge.  If you
       merge a commit, but the dependencies are rejected, we're going to
       have to revert.  You need to make sure there is good alignment on
       the direction across all the commits in the topic before
       accepting.

None that this currently doesn't affect openbmc/openbmc recipe bump
commits.  We'll still need to manually rebase and/or squash those to
ensure the proper merge order.  AndrewG and myself usually keep an eye
out on those and take care of it.

[1]: https://gerrit.openbmc.org/c/openbmc/openbmc-build-scripts/+/74987

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20241002/1fc21ec2/attachment.sig>