Exploratory Proof of Concept

The scope of this is still being discussed and some points are missing, others might be removed.

Build a small proof of concept to explore the following:

• High-level sketch of the data structures and core logic, without too much focus on actual implementation details
• Automatic rebuild detection and invalidation: Analyze a common rebuild situation and try to compute what rebuilds are necessary
• Create buildsets for trivial version bumps as well as rebuilds
• "Linearize" multiple parallel conflicting build namespaces for hypothetical release, similar to gitlab's merge trains (#25)
• Automatically create new build iterations when package sources change
• Allow for smooth development & automated testing using fake dummy builds
• Run builds using a gitlab runner custom executor (#26 (closed))
• Evaluate whether gitlab can handle the amount of issues, pipelines, and merge requests we would create (#27)

Maybe part of the Poc:

• Link to individual package builds across source repositories using central issues or merge requests (#28)
• Look at common bootstrapping problems and brainstorm ways to handle them (#29)
• Create Gitlab MRs, show build status in their pipelines (#30)
• Explore how to re-use build artifacts between multiple iterations (#31)

Not part of the PoC:

• buildbot, or any other solution for distributing build workload across multiple machines
• Functionality for releasing anything to a pacman repository

CLI commands

• build
• logs --job=<id>
• status [--buildset=<id>]