In T101358#1582108, @mmodell wrote:
We can generate the callsign mapping in phabricator. One option that @demon and I came up with is to offer a static url, something like https://phabricator.wikimedia.org/r/project/mediawiki/extensions/Flow/ which would simply redirect to https://phabricator.wikimedia.org/diffusion/EFLW
Until this is implemented, various git templates on mediawiki.org (e.g. Template:Git_file) rely on Module:Callsigns to map gerrit project paths to callsigns.
| Restricted Differential Revision | |
| Restricted Differential Revision | |
| Restricted Differential Revision |
For reference:
#switch is a terrible idea to store such map:
The Gerrit project name and Diffusion names do not match and are inconsistent (the last created project names in Diffusion have / as separator whereas it was a dash previously). Might have an impact as well.
What about having the Phabfile template to use the callsign? It is more or less meant to be an immutable human friendly ID and saves the crazy #switch.
So instead of:
{{phab file |project=mediawiki/extensions/Flow |file=composer.json }}Do:
{{phab file |callsign=EFLW |file=composer.json }}And the lookup map is gone.
That is what Module:Callsigns is doing and this task is about using Phabricator instead to handle the redirection.
What about having the Phabfile template to use the callsign? It is more or less meant to be an immutable human friendly ID and saves the crazy #switch.
Well, that's my question from T101358#1342162:
what's the most "correct" and future-proof way to specify a repo ?
Converting several thousand invocations of {{git file | project=path/to/repo }} to {{git file | callsign=XXXX }} is non-trivial but if the latter is the correct specification, we can consider it. But even with callsigns and eventually phabricator/diffusion as our git "origin" remote, it seems to me we still need some way to indicate to developers "Clone this repo in your mediawiki/extensions/BoilerPlate directory structure". So does path/to/repo go away?
@mmodell, can you comment?
@demon: Do you have a list of the repository callsigns mapping to the old project urls? I can build the redirect script but we need to have that mapping somewhere and the only version of such that I have available is far out of date at this point.
This is everything as of a ~week ago:
I haven't gone and created any repos since then really so it should be most everything minus the ~30-50 repos that haven't been imported yet. Even when new ones are added to the list these will remain unchanged.
The comment https://secure.phabricator.com/T4245#135441 sounds promising:
Yeah, I'm planning to convert the "Clone As" setting to "optional, unique repository name" and use it as an identifier in URIs if it's set.
That sounds good, but then I'm confused by https://secure.phabricator.com/T7938 "Do not allow users to enter things like "/" or ".." in the "Clone/Checkout" field in repositories". Our Clone field (e.g. https://phabricator.wikimedia.org/diffusion/SEXA/) shows
git clone https://gerrit.wikimedia.org/r/p/mediawiki/skins/Example"
@demon: the phabricator redirection rules are now deployed on iridium, can you configure gerrit to use these url patterns? (I included the a theoretically valid gerrit config snipped in the commit log for rPHEXd724c51a4144: Add more redirection url patterns for gerrit urls)
I believe that once gerrit's config is updated this task can be closed.
Actually, before we can close this we need to point git.wikimedia.org at phabricator. But for now we can tell gerrit to redirect to phabricator.wikimedia.org instead of git.wikimedia.org
Change 256262 had a related patch set uploaded (by Chad):
Gerrit: use Diffusion for repo browsing
Could these redirects be set to active on phabricator because someone has changed the links to things like https://phabricator.wikimedia.org/r/project/mediawiki/extensions/Echo even though the redirects aren't active yet. https://www.mediawiki.org/wiki/Extension:Echo
More useful to see the diff: https://www.mediawiki.org/w/index.php?title=Template:WikimediaDownload&diff=prev&oldid=1954487
Would it be possible to only replace the base url path (from /r/project to /diffusion) and the project path (project repo to callsign) and keep all other URL paths?
e.g. If want to get to the REL1_25 branch of mediawiki/core with the redirect I would be able to use https://phabricator.wikimedia.org/r/project/mediawiki/core/browse/REL1_25/ and it would be redirected to https://phabricator.wikimedia.org/diffusion/MW/browse/REL1_25/.
This would be for T101358 to preserve the file and branch features that are currently built in to {{Git file}}.
Change 256605 had a related patch set uploaded (by Hashar):
Gerrit: use Diffusion for repo browsing (again)
Can we support query parameters such as ?view=raw and ?blame=1 as well? Right now it appears the redirect strips the query parameters.
https://phabricator.wikimedia.org/r/browse/mediawiki/core;master;composer.json
https://phabricator.wikimedia.org/r/browse/mediawiki/core;master;composer.json?view=raw
https://phabricator.wikimedia.org/r/browse/mediawiki/core;master;composer.json?blame=1
That would make https://www.mediawiki.org/wiki/Template:Git_file more convenient by not maintaining call signs in two places.
Though ideally Phabricator would just allow using the dashed versions of the repo names in the url instead of requiring these awkward callsigns everywhere.
It seems that none of the links are working correctly in gerrit now. Since it is hard to find a link in gerrit that links to just browse the repo. Clicking on revision brings you to a link that does not exist. Same for clicking on branches.
I think a redirect script needs to be created for revisions and branches. I know revisions wont work if they aren't merged yet. But ones that have been merged. Other wise the updated link in gerrit is use less.
If you looked at the redirect script you would see that it accepts both revisions and branches. Patches welcome if it's not working.
I think it is too do witht the redirection in gerrit. I will upload a patch and see if that fixes it.
I think a redirect script needs to also be created for branches. since projects are hard coded. It should either be done automatically meaning that script can be created so that it is not hard coded.
Uploaded patch here https://gerrit.wikimedia.org/r/#/c/257193/ and here https://gerrit.wikimedia.org/r/#/c/257192/
Gerrit links now work.
Just branches doin't since they use for example refs/heads/REL1_26 a redirecter script needs creating to redirect branches by removing refs/heads
Right, that's the last bit that needs fixing here. When using branches we just want the bare branch name and not the fully qualified one. To be extra fancy, we could do the same for refs/tags too, it wouldn't be hard while we're there. Nothing's linking that at the moment that I can think of, but Gitblit might need such a redirect at decom.
Branches redirection link has been fixed all working now. Except from refs/meta but that's because phabricator isen't pulling from that ref.
I think this can be closed now.
All that needs to be done is to allow viewing open patches in phabricator.
Change 257523 had a related patch set uploaded (by Dzahn):
Gerrit: redirect old gitweb project urls to Diffusion instead of Gitblit
Change 257523 merged by Dzahn:
Gerrit: redirect old gitweb project urls to Diffusion instead of Gitblit
Could I ask what does the link look like for you. Not all repos are in phabricator yet so redirects won't work if the repo Isent in phabricator
While clicking on "diffusion" button on any gerrit patchset I find a 404 Not found message on phabricator's side.
e.g. on page
https://gerrit.wikimedia.org/r/#/c/261328/
clicking on "diffusion" button of PS1 I get this link
https://phabricator.wikimedia.org/rGTWNb7c401d228acadd2862efb365eaa10622df8037d
which shows me a "404 Not found" message box
The link won't work if the patch is open. If the patch is merged then it should work.
The link won't work if the patch is open. If the patch is merged then it should work.
How senseless is that!
It means that if the patch is open on gerrit and not merged yet then the link will not work. If the patch is merged in gerrit then the link will probably work.
This is a know issue.
Only for the latest patch and only if the sha1 didn't change when it was closed (ie it just fast forwarded)
Anyway it is a inappropriate way of implementation of a currently senseless link which is only working when a patch was reviewed. The previous gitblit was very helpful for reviewing patches because you could see all diff of all affected file in one view whereas the remaining gerrit diff links (side-by-side and unified) shows one file only and it needs minutes to show a single page which is just horrible for a review process. Please give me gitblit back.
Hi gitblit is still there. git.wikimedia.org you just need to enter your url manually.
And they are going to start importing patches from gerrit.
@Xgt I doint know when they will start doing that. But they said once they finished they are going to put gerrit in read only mode and so patches would need to be uploaded to diffusion once it has been turned on for every one to use.
@demon does that it batches. And also from now when some requests a repo in gerrit it will also be done in phabricator and also the redirection script is also done in batches and so even if the repo exist the redirection script has to be updated.
We'll probably yes but when repos are created in gerrit they are not automatically added to this redirection script.
Reopened. "Diffusion" link still gives 404 message as long as patchset was not merged.
Yes, maybe if it fails we could redirect to git.wikimedia.org as a temp solution since we haven't migrated from gerrit yet.
Since rPHEX0beee3a5fe01 , the repo name -> call sign mapping is in Phabricator. We should then get rid of the manually maintained https://www.mediawiki.org/wiki/Module:Callsigns but I am not sure which task to use for that (maybe a new one).