I’m new to pulp and have been studying the documentation and feel like I’m missing something. I understand how to setup the repositories, remotes, sync etc. Now I want to setup a typical dev/qa/prod flow for repositories. Dev repository would sync with external repos and then get promoted through qa and prod. Promotion — Pulp Project 3.19.0 documentation outlines the workflow, but I think assumes a bit of knowledge about interacting with the API that I’m lacking. Does anyone have working examples of how to do this type of operation? I’m hoping for something that can use the pulp cli, but httpie commands would also work. I need to perform this workflow for RPM, DEB, and File repositories.
2 Likes
The idea is based on the fact, that repositories in Pulp are versioned. That means every time, you add/remove content, or perform a resync, a new repository version is created, but the previous one is retained (with a lot of deduplication machinery in the backgroud). All of these repository versions are immutable and can therefore be seen as a record of the repository content in time. Now, for RPM, DEB and File content you need publications to add the necessary metadata to the repository versions. Let’s just assume, we have a one to one correspondence there.
Your software lifecyles are now modeled by distributions pointing to specific publications at any point in time. A distribution connects a publication with a web address on the content server and performs optional access control. Promoting the current dev environment to qa is now performed by rewiring the qa-distribution with the publication currently served by the dev-distribution (at that point they will serve the same bits).
Example:
pulp file distribution show --name file-dev
will tell you the path and publication of the dev distribution.
pulp file distribution update --name file-qa --publication "$(pulp file distribution show --name file-dev | jq -r '.publication')"
will link qa to the same publication (promote the content).
Please keep in mind, that Pulp may be seen as the rather unopinionated toolbox with which you can support such usecases. You would probably want to build some automation around your specific workflow.
2 Likes
Many thanks for your reply and examples! This makes sense, but let me be sure I understand. If I update the qa distribution to point at the same publication as dev, am I still free to re-sync dev repo with upstream? (in the case or RPM let’s say.) Any changes to dev repo upon sync would create a new repository version and a new publication would be created based on that version with no affect on the previous publication that was promoted?
1 Like
Yes exactly. And depending on the configuration / automation, the dev distribution would start pointing to that new sync right away without changing what QA sees.
1 Like