Closed Bug 1316273 Opened 8 years ago Closed 7 years ago

Support custom repository branches

Categories

(Webtools Graveyard :: Pontoon, defect, P3)

Product:
Webtools Graveyard
Component:
Pontoon
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mathjazz, Assigned: thecount)

Details

Pontoon can only pull from/push to default repository branch.

For various reasons (protected branches, commit history pollution, etc.) project authors sometimes prefer Pontoon to push to a different branch. We should support that.
Been poking around on this bug.

So far, I have Pontoon running locally, and just need to connect it to a test repository so I can test it.

So I'm guessing I need the test repo to have my local pontoon as a contributor, so it can make commits? Is the github contributor for local dev still mozilla-pontoon?

Another question, when I'm in the project admin page, I see a field for "Download prefix:" which is mandatory. Not sure what this is or what should go there.

In general, I think I need to find some docs on connecting pontoon to git from the pontoon admin side of things. Or any other links that may help. Thanks.
Hey Scott, thanks for digging into it!

For testing purposes, we usually set up repositories in personal GitHub accounts. Your development machine should already have write access there, so Pontoon should be able to push out of the box.

Download prefix is a hack around Heroku's ephemeral storage. Since you won need it, simply type any string into the field:
https://github.com/mozilla/pontoon/blob/master/pontoon/base/models.py#L1087

Our project management team uses these docs for adding projects:
https://github.com/mozilla-l10n/documentation/blob/master/tools/pontoon/adding_new_project.md

We should probably keep a stripped down version of it in developer docs. We can also do this as part of bug 1203788 (current version is accessible at http://localhost:8000/a/ locally).
Thanks, that's helpful and got me further.

So, I added a new project, but it's not showing up in the project list. I can only see it under Admin.

So, instead I tried to change the default Pontoon Intro project to point to a fork of that repo, and made some changes, but I have not seen any commits to the repo yet. Do I need to approve changes or is it automatic?
I wonder, from a VCS and project setup POV, this should be a setup similar to one where l10n and en-US are in separate repos, right? We probably also need to maintain two working copies during VCS sync?
(In reply to Scott [:thecount] Downe from comment #3)
> Thanks, that's helpful and got me further.
> 
> So, I added a new project, but it's not showing up in the project list. I
> can only see it under Admin.

Yeah, you need to sync Pontoon with the repo , so it can import the necessary strings and expose the project for translation. In local development environment, sync needs to be triggered manually:
./manage.py sync_projects YOUR_PROJECT_SLUG

Only added/deleted translations have impact on sync, suggestions don't. If you're logged in as superuser, you will submit translation by default (marked with green icon, blue represents suggestions).
That fixed the one problem, project can load now, but making changes still won't commit to my test repo. I'll debug more tomorrow night, but it feels like I'm missing something obvious. It's not throwing any errors, and is somehow loading my changes after I change something in pontoon. But github is still old stuff.
Ah, got it to sync! OK, I should be good to do this bug ;)
Excellent! Let me know if you have any further questions or stop by in #pontoon.

(In reply to Axel Hecht [:Pike] from comment #4)
> I wonder, from a VCS and project setup POV, this should be a setup similar
> to one where l10n and en-US are in separate repos, right? We probably also
> need to maintain two working copies during VCS sync?

I'm not sure. In multiple-repo scenario, multiple Repository instances need to be specified during project setup. In our case we need to add an optional "branch" field to the model:
https://github.com/mozilla/pontoon/blob/master/pontoon/base/models.py#L1068

The only change this bug brings is that Pontoon syncs with the custom branch instead of the default one.
(In reply to Matjaz Horvat [:mathjazz] from comment #8)
> 
> The only change this bug brings is that Pontoon syncs with the custom branch
> instead of the default one.

Is that actually the intent?

I would have expected the intent to be "take en-US strings from master, push localizations to pontoon-dump"
Blake, could you please help us clarify this?
Flags: needinfo?(bwinton)
I think there's value in using the same branch for en-US and l10n, e.g. you can expose new strings when you're ready on the branch, and move on with development on master.

The only cons of that is that you need to keep en-US in sync between master and branch.
Given that I currently need to keep en-US in sync between master and an entirely separate repo, the way Scott implemented it seems good to me.  ;)

Also, I think that if I specified a branch, I would expect Pontoon to only use that branch, not to pull stuff from some other (non-configurable) branch.
Flags: needinfo?(bwinton)
... having thought about it some more, there's probably a semi-canonical extension to "one repo with one non-default branch" to "one repo with two branches".

It'd be good to implement the first such that we can add the latter with limited impact.
I have a WIP pull request here: https://github.com/mozilla/pontoon/pull/538

It's working in my tests, but I'm pretty new to Python and the Pontoon source, so I could use some feedback :)

I can see value in having en-US on master, if it's configured that way, but I also see value in having en-US on an l10n branch. Either way, needs to be explicitly configured that way.

Having the ability to commit to a branch other than master feels like a step towards both of those goals.
Oh also, how do we want to handle this for other types of revision control? I'm not super familiar with hg or svn, so not sure how a branch equivalent would work, or if it's even valuable.

I think ideally we do this in a way where it works for Git, and is easy to add to hg or svn if required. Thoughts?
Mercurial has two concepts in this realm:

- branches are metadata for the commit
- bookmarks are symbolic names for heads, and semantically like git branches

We can probably support bookmarks in the same fashion as git branches, mercurial branches are harder.

In SVN, branches are just paths in the upstream repo.
More questions: Should there be a validation step that the branch/bookmark actually exists upstream?
Yeah, a validation step would be pretty nice. Although, it doesn't look like it currently does validation for the github url field, I can type in nonsense, and it creates a project.

In regards to svn and hg, would this be a useful feature based on their workflows? We can either add support to those now, or do it in a later patch. I would prefer a later patch ;). In both cases, we need to figure out what to do with the input label. Maybe change it to "git branch" in the case of only supporting git, and "branch/path/bookmark" in the case of supporting all three.
Assignee: nobody → scott
Added review notes on GitHub.

Validation would be nice, but I think it's out of scope of this bug.

So far Pontoon hasn't made any distinctions between different repository types and it would be nice to keep it that way. But I'm OK if this is a Git-only feature for now and we file a bug to extend it to other VCS types later. At this point it doesn't seem likely anyone would need custom branch support in either HG or SVN.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.