Transition from build.neon.kde.org (Jenkins) to invent.kde.org (Gitlab)
Random brain dump:
- neon currently relies HEAVILY on old jenkins jobs being ordered based on their dep tree, to ensure build consistency. this doesn't exist in gitlab and raises the enormous question of how to ensure that kmail builds after akonadi when both are queued, particularly when both have been queued outside tooling control (e.g. they were both pushed to)
- there are a great number of management/maintenance jobs that run. do we put them all in a repo each?
- there is one merger job, per packaging repo, that auto-merges the Neon branches (neon/release -> neon/stable -> neon/unstable). how do we deal with this?
- neon pipelines do need to shuffle about a host of data - how to best do that with gitlab?
- neon ci is largely backed by build servers from blue systems - they'd need to get tied into gitlab for use by neon but not be used by any non-neon jobs
- neon ci also creates ephemeral droplets in a blue systems sponsored digitalocean team, with different core counts (e.g. a job that needs only two cores generally only gets two cores) - that also needs to get tied into gitlab for use by neon but not be used by any non-neon jobs
- cloud nodes need to run a special provisioning script before use and get discarded when not in use
- cloud nodes are technically provisioned from a base image that uses usernamepsace'd docker
- two two special node types in that cloud that require special provisioning scripts to run (as root). namely: iso, which removes usernamespace for that one node type. snap, sets up a snap-compatible build env
- builds only ever run on their suitable node type (2cpu builds run on 2cpu nodes, 4cpu on 4cpu nodes, iso on iso nodes, ... - if there are none they have to wait)
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information