[Pulp-list] Synchronize Git Repositories: Crazy?

Bryan Kearney bkearney at redhat.com
Thu Sep 3 16:28:49 UTC 2015

On 09/03/2015 09:50 AM, Michael Hrivnak wrote:
> On Wed, Sep 2, 2015 at 4:27 PM, Scott McCarty <smccarty at redhat.com
> <mailto:smccarty at redhat.com>> wrote:
>     All,
>          I had an epiphany the other day, that I would love to be able
>     to synchronize an entire stack:
>     1. RPM Content for OS
>     2. Puppet Modules to configure
>     3. Docker Images built from the above
>     4. RPM Content for Ruby Runtime
>     5. Gems for Ruby application
>     6. GIT repo for my code
>     I see Python module support being added, so I suspect that Ruby is
>     on the radar, but what about synchronizing my entire latest tag in
>     GitHub? Then I could have my entire stack cloned in time right? Then
>     if I ever wanted to go build that exact version of the application,
>     it should be easy. Am I crazy?
> I think this idea makes a lot of sense. We should facilitate managing
> the entire lifecycle of artifacts that come from the source, including
> archives of the source itself.
> Ruby is on the radar, we but don't have plans to start on it in the near
> future. If there are any volunteers interested in helping though...
> Git is an interesting scenario that's come up before, but its very
> nature makes it complex to manage with pulp. Although to be fair, we've
> had to solve many of those challenges while implementing ostree support.
> A simpler and more portable (works for non-git VCS) way would be to
> store the source and any patches in pulp as regular files, or maybe just
> one tarball. This would make it clear that pulp should not be used as a
> VCS, but can be used to store archives of the code that was used to
> produce a specific build. Pulp doesn't have explicit support for
> managing "file repositories" yet, but that's definitely on the radar to
> implement. And in truth, our current "ISO" repository support can be
> used to manage any files, and many people do use it to manage tarballs.
> It probably should have been named "file" support to begin with.

So.. if you want a different use case look at r10k. r10k handles the 
"pull this branch from git and drop it on this environment for puppet". 
If pulp supported a git branch concept, we could use this in satellite 
by saying to pull the latest (or tag) and deploy that. It would be a big 

-- bk

More information about the Pulp-list mailing list