[Pulp-list] Synchronize Git Repositories: Crazy?
mhrivnak at redhat.com
Thu Sep 3 13:50:46 UTC 2015
On Wed, Sep 2, 2015 at 4:27 PM, Scott McCarty <smccarty at redhat.com> wrote:
> 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-list