# Repository management vs. Build management <!-- Put the link to this slide here so people can follow --> slides: https://hackmd.io/@GRN2rv-rSjewIIIPe8YqgQ/rJov3sRPA --- ## What is Pulp / Repository Management Primarily a *repository management* system. Repositories are the primary object of manipulation. All content must exist in a repository, and you tend to add the smallest invidiual unit of content at any given time (e.g. a package) --- ### What is build management There is sometimes a higher conceptual level abstraction beyond individual packages. One spec file can turn into many RPMs when built - and there may be more than one group of RPMs if built for many different architectures. Sometimes you specifically want to manage *builds*, atomically ensuring that either all packages in a build are present or they are not. Interim states where individual packages have been added are undesirable. --- You *can* emulate this with Pulp, and we do (e.g. COPR), but it does involve a bit of additional automation outside of Pulp. Pulp doesn't natively support this workflow. It's an interesting thought exercise to think about what supporting a native workflow might look like. --- ### Example: flat-manager https://blogs.gnome.org/alexl/2019/03/19/introducing-flat-manager/ Flat-manager is the backend for Flathub, the primary community flatpak repository. --- ### flat-manager workflow: * Create "build" * Get "ID" * Upload artifacts to the build ID * "Commit" the build when finished, or "Purge" the build if anything failed * New "test" repo created automatically when build is committed * Purged builds are never made available to users --- * "Publish" * Sign artifacts * Produce derivative artifacts * Static deltas, appstream metadata, flatpakref files * Call scripts for customization --- "Publish" is split into *two steps* * Import (the build, into the mainstream repo) * Separate job is queued to perform repo updates * That way, if multiple builds are published at the same time, the update can be shared (no race between A / B publishes) Analogous to "Copy Content" + "Publish" in Pulp terms. Flathub has a default policy that successful builds are published after 3 hours. --- How you would emulate this in Pulp: * Create a "side" repository for each build (probably with a 1-version-limit). Maybe do this per-arch. * Upload packages there, treat it as a mutable staging area * Publish and distribute the staging area within some namespace for test repos * Copy the contents of those repositories back into the mainstream repository, and delete the "side" repository. --- Pulp gaps vs. flat-manager * "Purging" doesn't really exist, artifacts from deleted repos just become orphaned and are later garbage collected at some unknown point. * Intermediate states always have to be a valid repository, because that's what Pulp is designed around. Imagine building a module (or something like a module - with cross-references). You can't upload a *partial content* incrementally and then "commit" when done and still get correct results.