Open Stack

James E. Blair wrote:
> Thierry Carrez <thierry at openstack.org> writes:
> 
>> To script milestone-proposed branch creation, it looks like granting
>> createReference to "Release managers" on refs/heads/proposed/* would do
>> the job (although maybe the current "push" permission on
>> "refs/for/refs/*" might already be enough). Then I suspect I could "git
>> branch proposed/icehouse-1 $SHA && git push gerrit proposed/icehouse-1".
>>
>> To script milestone-proposed branch deletion... looks like we'd have to
>> allow push +force on the same refs. Not exactly sure how you git-push
>> the deletion of a branch, but the git/gerrit experts on this list should
>> be able to tell me.
> 
> The thing we don't want to do is grant push (with or without force) on a
> branch itself ('refs/for/...' is probably fine).  That is dangerous as
> it allows you to bypass code review.

Right, as far as I can tell that prevents us from deleting branches... I
never succeeded to grant "Push+Force" to refs/for/* (suggestions welcome
on how to express that in the UI), but I suspect that would not work for
branch deletion.

> Also, it's probably worth looking into the state of the REST api, both
> in 2.4 (unlikely) and 2.8 or 2.9.

Delete branch is in 2.8 REST API.

So my suggestion would be to quickly implement branch creation using git
push (Release managers already have "Create Reference" on refs/* so it
probably already works). I can try that for icehouse-1

Second step would be to switch from milestone-proposed to proposed/*,
which involves (afaict):

- for every project, modify refs/heads/milestone-proposed access rules
so that they apply to refs/heads/proposed/* instead
- special-case proposed/* in {name}-branch-tarball job template shell
script (in
modules/openstack_project/files/jenkins_job_builder/config/python-jobs.yaml)
so that it still builds generic PROJECT-milestone-proposed.tar.gz tarballs
- update merge_tags.sh so that it looks into proposed/* rather than
milestone-proposed
- anything I missed

The goal would be to have that done for icehouse-2.

Then as a 3rd step we can wait for Gerrit 2.8 before implementing branch
deletion using the REST API. Or we can wrap it in an automatically-run
post-release job. As mentioned in my original email, that job would need
to differentiate between intermediary milestone branches (which need to
be deleted at the end of pre-release) and the release branch (which
should should stay alive until final release and be converted to stable/*).

-- 
Thierry Carrez (ttx)