English
At this point, your builds have landed in the stable tag in Koji, it is therefore available in the buildroot for anyone to use and rely on and the corresponding Bodhi update has been marked as stable.
Bodhi is notified that your builds were signed and moved to this tag by our message bus, it will mark the builds as signed and once all the builds have been signed, it will move the update to the ``Testing`` status.
Bodhi will listen to the bus for the decision made by Greenwave about updates. Upon receiving them it will push the corresponding update into the final Koji tag (i.e. the stable tag) and mark the update as ``Stable``.
Bodhi will then create two side-tags:
For compiled packages that rely on a certain ABI or soname, it is easy to understand how they are tightly coupled. However, non-binary programs can also have such strong dependencies.
For example, the packages link:https://src.fedoraproject.org/rpms/python-urllib3[rpms/python-urllib3] and link:https://src.fedoraproject.org/rpms/python-requests/[rpms/python-requests] are heavily linked. Updates to python-urllib3 need to take python-requests into consideration. Sometime the update is fine, sometime it needs to wait for a new version of python-requests, in which case both builds need to be tested together as one unit.
How Does Gating Multi-Builds Updates Work?
If you have created a side-tag and have no use for it (and did not create an update for it), please remove it so it does consume resources on the build infrastructure. You can simply remove side-tags you have created using ``fedpkg remove-side-tag`` and you can list your side tags using ``fedpkg list-side-tags --user=<username>``.
If you need to chain-build some packages and you want to be sure the previous one is available in the side-tag buildroot, use: ``koji wait-repo <side-tag-name> --build=<build-nvr>``.
{imagesdir}/Simplified_multi_builds_update.png
Multi-Build Updates
Multi-build updates contain multiple builds that are tightly coupled together.
Note that the update being `stable` does not mean you will be able to install it via dnf/yum. It means the build is available in the Rawhide buildroot. It will be pushed to the mirror once the next Rawhide compose succeeds.
Once you have built all the packages in your side-tag, you can create the bodhi update for this side-tag using either:
Our change proposal (the one approved by FESCo): link:https://fedoraproject.org/wiki/Changes/GatingRawhidePackages[]
Our project’s requirement document: link:https://fedoraproject.org/wiki/Infrastructure_2020/Rawhide_Gating[]
Packages of this style are candidates for the multi-build update workflow. They need to be built and tested together.
RoboSignatory is notified that your builds landed in this tag by our message bus, it will take them, sign them and move them to the ``<your-side-tag>-testing-pending`` tag.
Simplified diagram of the multi-builds updates workflow
Tests will be run, their results will be reported to ResultsDB which will announce these results, making Greenwave consult each `gating.yaml` file to see if all the required criteria of these builds have been met or not. If they have, Greenwave will send a message to the message bus announcing its decision.