<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 2, 2015 at 4:27 PM, Scott McCarty <span dir="ltr"><<a href="mailto:smccarty@redhat.com" target="_blank">smccarty@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">All,<br>
    I had an epiphany the other day, that I would love to be able to synchronize an entire stack:<br>
<br>
1. RPM Content for OS<br>
2. Puppet Modules to configure<br>
3. Docker Images built from the above<br>
4. RPM Content for Ruby Runtime<br>
5. Gems for Ruby application<br>
6. GIT repo for my code<br>
<br>
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?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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...</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Michael</div></div></div></div>