The Build Pipeline Overview (BPO) component is a read-only user interface (UI) that will provide information about the build process of modules.
WHY
Information about module builds are scattered all over the place - in BPO, Koji, Bodhi, mirrormanager, ...
There should be one UI that would show you all the information needed.
WHAT
This page describes the first minimal version of BPO.
It will be focused on developers and release engineers. Later versions should be also focused on QA people, PMs, and end-users.
The first version should:
- be ready* for flock
- help people understand the whole concept
- be subject to discussions, changes, extensions, ...
* Take this as a proposal by asamalik - it is nothing official or agreed at this moment. Ready would mean some initial hackish implementation that would help people to see the build process.
WHAT - the usability side
The first version will be focused on developers and release engineers with the following use-cases:
Developer:
- patches a package (component) for CVE and wants to see
- which modules will be rebuilt and status of these rebuilds
- creates/updates a module and wants to see
- a state of the build process of this module
- a list of modules that depend on this one and will be rebuilt and status of these rebuilds
Rel-eng:
- a CVE has been patched in a package (component) and they want to see:
- list of artifacts affected by this update
- build states of modules from which are the artifacts composed
- "all green" meaning everything has been rebuilt = CVE fixed everywhere, so they can make a press release about it
There will be other people with roles like QA, PM, end-users. Their use-cases will be covered in later versions of the BPO.
WHAT - the technical side
There will be three entities:
- components (RPM package)
- modules
- artifacts (modular repo, iso, docker image)
And there would be three basic functions:
- Search components, modules, and artifacts.
- Browse 'relations' between components, modules, and artifacts.
- See details of components, modules, and artifacts.
Details would as follows:
- Detail of a component
- list of modules in which is this component included
- build state of these modules
- list of artifacts in which is this component included
- Detail of a module
- list of components included in this module
- list of modules that are dependencies of this module
- build state of these modules
- list of modules that depend on this module
- build state of these modules
- list of artifacts that are composed with this module
- Detail of an artifact
- list of modules that are included in this artifact
- their build states
Relationships
A module has the following relationships. The UI should allow to navigate trough these relationships to see details of other modules. It should also show the build states of all of these.
Build states
The build pipeline and corresponding build sates are shown on the picture below. The interface should show the state of a module in this pipeline.
HOW
This is a question for the next sprint #10.
The BPO would be probably:
Read only. Web UI + API.
Database that would remember everything and will be updated by: - querying other components - listenning to fedmsg