story #11477 have a dedicated reference for pullrequests
have a dedicated reference for pullrequests

I can manage branch deletion, continuous integration, etc

Functional overview

As it's mainly an internal refactoring, there are very few functional changes. However the following things will change:

  • Continuous integration can be more reliably associated with the PR (as the verification of the PR will be defined in the target repository, not in the source as of today)
  • It will be possible to browse PR associated to a deleted source branch (not possible today)
  • Better performances for merge

Technical changes

At pullrequest creation, a new reference will be created in the target repository. The namespace will be refs/tlpr/ and the PR will be numbered starting at 1:

  • First pullrequest will create refs/tlpr/1/head
  • Second will create refs/tlpr/2/head
  • etc

A new commit in the source branch will automatically update the reference (not create a new PR). Hence the target namepace will be "rewindable" that is to say that refs/pr/1/head history can be rewritten if source repository was rewritten.

The intermediate repository for merge will no longer be used.


  • forgeupgrade bucket to assign a PR id per repository starting 1 for each PR / repo.
  • a new PR will create a new reference in refs/tlpr namespace
  • a push in source branch of a PR (as long as the PR is open) generates a push --force in corresponding refs/tlpr/X/head
  • a merge of PR is merge of refs/tlpr/X/head in the target branch
    • As result refs/tlpr/X/head is no longer updated
  • at repository fork (in project or across projects) doesn't clone refs/tlpr namespace
  • pullrequests backend (REST) updates
    • diff generation
    • merge
  • pullrequests UI updates
    • Add info in the UI "how to fetch PR locally?"
  • pullrequests Continuous Integration updates
    • CI now targets the pr itself (must be configured in target repo)
    • Snippet to be deployed on jenkins is updated
  • git/gitolite backend updates
    • refs/tlpr namespace is Readonly
  • all existing PR are converted to refs/tlpr/X/head
    • there is an async job (root_daily to do it in background)
    • when someone access a given PR there is a conversion step first before they can go to the PR
  • xml import/export
    • nothing is done but code should be able to manage that a given pr cannot be created because the ref already exists
  • [ ] Does it involves User Interface? 
  • [ ] Are there any mockups?
  • [ ] Are permissions checked?
  • [ ] Does it need Javascript development?
  • [ ] Does it need a forge upgrade bucket?
  • [ ] Does it need to execute things in system events?
  • [ ] Does it impact project creation (templates)?
  • [ ] Is it exploratory?
Manuel Vacelet (vaceletm)
2018-06-21 16:33
2018-05-14 15:48

Referencing story #11477

Git commit