Hi all. You may remember that we've previously developed a tool called firehose to generate candidate changes to Baserock's definitions, based on upstream's changes. We previously developed it to push changes to gerrit, with the idea that we would be using some of OpenStack's tooling to perform tests on these candidate branches. Current thinking is that now it should be fed through a CI pipeline before candidates are posted, to reduce the amount of noise from candidates proposed by automation, which are subsequently rejected by automation. So currently we're working with an older version which has rolled back to before it was made to only be able to work with gerrit, with the intention of resurrecting the useful code at a later stage in the pipeline, after we have some confidence in being able to make use of the change. This would have the benefit of also being useful for projects not using Gerrit for code review, as a human could watch the pipeline and merge the candidate changes manually. This is the first element in the pipeline shown in http://52.19.1.31:8010/waterfall We're not yet where we need to be with this, as no iteration of Firehose allows it to integrate multiple candidate branches simultaneously. The original design specified that Firehose should allow this, but given it may need a redesign to not depend heavily on morphlib and morph's internal behaviours, there's an argument for working around it rather than developing it further, and impose an external mechanism to meet our needs. The simplest version proposed is to require integrators to manually group sets of integrations, probably by directory, such that everything in a directory is configured to use the same landing ref.