Is it possible to allow push but disallow pull?

[Angel Ezquerra Moreu]

On Tue, Feb 21, 2012 at 7:40 PM, Stephen Morton
<stephen.c.morton at gmail.com> wrote:
> Angel Ezquerra Moreu wrote:
>>
>> Hi,
>>
>> one of our teams would like to make sure that the heads on their
>> central repository always build and pass certain tests. They want the
>> process to centralized and be as automated as possible.
>>
>> To do so they'd like to use a "build and test server" which would
>> serve as a sort of gatekeeper. People would always pull from an
>> "official" repository whose revisions are guaranteed to pass certain
>> tests, but they would never push to that official repo. Instead people
>> would push their new revisions to the "build repo" in the build
>> server. The build server would have a hook (or perhaps have jenkins
>> installed) that would run whenever a new set of revisions are pushed
>> to it. This hook would check the new revisions and if they were ok it
>> would push them to the "official" repository. That is:
>>
>> - If the build were successful and the tests passed the build server
>> would tag the topmost revision and push it to the "official
>> repository".
>> - If the build or the tests fail the server would strip the offending
>> revisions and notify the user that there was a problem (perhaps via
>> email).
>>
>> If two users tried to push to the build repo simultaneously only the
>> first one would be able to, because the second push would fail due to
>> the creation of multiple heads.
>>
>> The main problem (that I see) with this workflow is that someone could
>> pull from the build repo while it were testing some revisions. If the
>> tests failed the server would strip those revisions but they would
>> already be on the wild. Thus I'd like to find a way to let people push
>> to the build repository, but stop them from pulling from it.
>>
>> So my questions are:
>> - Is it possible to limit (or forbid) who can pull from a repo, while
>> still letting them push to that very same repo?
>> - Does this workflow make sense?
>> - Has someone done something like this? What were your experiences?
>> - Any alternatives?
>>
>> Thanks,
>>
>> Angel
>
>
> Since you asked for alternatives, so how about workflow... It assumes that
> designers are able to test their own work before pushing so that in general
> failure is not that common. It also assumes a general real commitment (as
> opposed to just a token commitment) to not break the build.
>
> Designers push to the build repo. There would be no blocking of pushes. Just
> keep adding to the tip.
> Integrators (ideally automated, not real people) run the tests on the
> tipmost changeset of the build repo. If the tests pass, the test repo is
> pushed to the official repo.
>
> If they fail:
>
> A nasty email is sent to the designer CCing everybody else telling them that
> they broke the build and that they'd better commit a fix fast.
> The integrator tool goes down the test repo history of un-pushed commits (if
> there is one) looking for the last working version that it can push to the
> official repo.
>
> Once a fix is committed, it will be the tipmost version and the whole
> history can be pushed to the official repo.
>
> Yes, this means there are some intermediate changesets in the official
> history that fail tests. So what?
> Yes, in a pathological case of people continuously breaking the build you
> could never push the tip of the build to official and some intermediate
> "good" changes could not be pushed. That's what I was talking about when I
> talked about a real commitment to not breaking the build. If that commitment
> is there, this problem does not exist.
>
> The issue that I see with this and any similar workflow is that there is
> some implicit merging happening. If you're pulling from one place and
> pushing to somewhere else which may have different code then you will have
> problems. I'd say you'd have to solve them with a model something like this:
>
> Designers pull and push from the build repo. Testers pull from the official
> repo. (The integrator tool pulls from the build repo.)
> There must be a hard rule that at a certain frequency (personally, I'd say
> no more than 30 mins) the tip of the build repo must be able to be pushed to
> the official repo. If not, there is hell to pay. (Again, that commitment
> thing.)
>
> I expect that this suggestion will be extremely unpopular with some people.
> But I actually think it sounds pretty good.
>
>
> Steve

Thank you Steve,

this is an interesting suggestion and we will take it into account.

Cheers,

Angel