Re: Push to remote repo

[Dan Nicholson <nicholson endlessm com>]

On Wed, 2015-10-21 at 09:56 -0400, Colin Walters wrote:
> On Wed, Oct 14, 2015, at 12:24 PM, Dan Nicholson wrote:
>  
> > This again assumes that the builder and the repo host are on the
> > same
> > machine, which seems unnecessarily restrictive. Currently, we pull
> > the
> > latest commit from the public repo to maintain history, make a new
> > commit on top of it, then rsync the entire repo back to the public
> > server.
>
> It's this last step that I'm suggesting can be replaced by
> having the public repo do a pull via static http.

Sure, that would make sense but make the builder setup more complicated.
I suppose you could spin up trivial-httpd rather than doing an actual
HTTP server setup requiring fixed paths. Hmm, but pull still requires
you to setup a remote in the configuration. And you now need the server
to have the public GPG keys to verify the pulled commit unless you want
to go to the trouble of setting up HTTPS.

>
Additionally, we could make it easier to pull, then re-commit
> with the existing binaries, but make a new commit.
>
> This would then change the flow to:
>
> 1) Private builder does a fresh build/compose without reference to
> public repo;
>     You now have a commit without a parent and binaries on the private
> repo,
>     let's call it
> 98ea6e4f216f2fb4b69fff9b3a44842c38686ca685f3f55dc48c5d3fb1107be4
> 2) Public repo pulls that branch/commit (could be exact commit if
> using
>    a messaging system)
> 3) Public repo creates a new commit, reusing the binaries, equivalent
> of:
>     ostree --repo=repo commit -b myos -
> -tree=ref=98ea6e4f216f2fb4b69fff9b3a44842c38686ca685f3f55dc48c5d3fb110
> 7be4
> 4) Public repo now has
> 98ea6e4f216f2fb4b69fff9b3a44842c38686ca685f3f55dc48c5d3fb1107be4 as
>    an unreferenced commit, so `ostree prune --refs-only` would GC it.

Yeah, that's a nice thing to keep history (although again orthogonal to
the mechanics of the push/pull). I've bent over backwards many times at
Endless to try to keep history on branches among our different repos,
but I've almost given up. It would be nice to have this as a sort of
"cherry pick" or "reparent" at the API level so that the temporary
commit is cleaned up immediately without having to enumerate all commits
via prune again.

One disadvantage of this approach is that you'd need to regenerate the
signature on the new commit object, which requires that the public
server has the GPG private key. One thing that would be neat is if
ostree could optionally prefer a parent commit from the detached
metadata. Then you could reparent a commit without actually creating a
new commit object. Not sure that actually makes sense.