We're experiencing the same for a single one of our (private) repo's. 6/7 of our repo's work just fine, but (un)lucky number 7 is giving us 404's all over the place... https://gitlab.com/comandi/dashboard
@DouweM@smcgivern ok so we have a problem with any project that has a name as reserved. I don't see another way except create a migration that will rename such projects. For example dashboard to dashboard1 etc
@dzaporozhets "Dashboard" is not an uncommon name for an (internal) software project, so I'm a bit hesitant to do that... How many repos would this migration affect on GitLab.com?
Would that create issues with out fancy nested namespace routing?
@DouweM no because dashboard used as top-level route only
How about projects or any other paths that were not previous reserved/
We must reserve projects, issues etc as its used inside group routing. So we keep it reserved. I will create a separate issue for migration to rename it .
Ok once https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8216 is deployed people with dashboard projects should be able to access it. Later I will make a migration to rename projects that we cant allow in routing like projects, issues etc.
Dmytro Zaporozhets (DZ)changed title from Repo 404 to 404 when visit project with reserved name
changed title from Repo 404 to 404 when visit project with reserved name
Would a project with create in the name be effected by this issue as well? Although the comments above mention projects with dashboard in the name, I'm currently experiencing 404 errors on https://gitlab.com/leadid-dev/create
Most of the links in the above mentioned tickets are now working but url ending with teams is still giving 404.
Example https://gitlab.com/_teams_/teams
I have a 404 issue for all group projects (all of them private), but none of the project names (or even group names) feature a reserved word. What's even weirder (I just found out today) is that a friend (who is also in the group) has no issues at all. I tried in two different browsers in two different operating systems and I get 404 in both. My rank is Master in both groups.
For reference, one project path is https://gitlab.com/vermilion/wp-proposal
Hi @markoooo, this was a different issue. I've managed to fix your issue on GitLab.com. If you're still seeing problems, please raise an new issue on the GitLab.com Support Forum issue tracker. Thanks!
Hey @markglenfletcher, thank you very much! I wanted to award you a 'cheers' emoticon, but there isn't one so I gave you a 'cheese' because that one is closest to 'cheers' when typing it... Anyway... Thanks! =)
Was it something I did to cause it (so that I know to avoid it in the future)?
@dzaporozhets I think we should keep it open for now as users that are still experiencing the problem are more likely to find an open issue. Thanks for persisting with the fixes for this
is possible to manually rename the affected project in some way?
@MannerMan it can be done via rails console using next code https://gitlab.com/snippets/34363. Although script is simple it will be slow for big amount of projects and I tested it only in dev machine. So I would not recommend it for production
@dzaporozhets@markglenfletcher what's the plan to fix links already indexed by Google? Or links already shared with other people? These are public repositories. IMHO, isn't this a big problem on renaming?
On my company's gitlab server, I have a project called "issues", which is a container project for all issues of that group. Can't access it anymore after 8.15, so I rolled back. Repository is mentioned many times in git commits, issues and merge requests, so renaming isn't something I really want to do.
Can't you guys do the check for blacklisted project names in the project creation step, and don't check when just accessing the project? Anyway, 404 on an existing project seems like a bad idea...
Seconding @jaapz, giving 404 for existing project without warning does seem like a bad idea. Maybe it is too late now, but for me it would have made more sense to use prefix or postfix for reserved paths. Instead of reserving issues, projects, all etc., using for example "_issues" or even "glissues" as the reserved path?
So I guess my questions is, would there be any way of getting existing names to work? Whitelist everything for now, but display a warning for the project so that users can at least update their tools and links and communicate the change?
In my case the most problematic one is "projects".
Just like @jsirpoma mentioned, reserved names should be prefixed with something not so commonly used. I would recommend two underscores like "__wikis", "__projects" etc.
Anyway to get projects renamed on gitlab.com thru support team?
I can't use the scripts above on gitlab.com ...
Or, any update when the new relase will be deployed which should allow access or renaming (my project is called 'issues', which will be forbidden even in future ... ) ?
would it be possible to whitelist everything now and not do a forced rename yet? To me it looked like this change was part of refactoring work which will really be needed only later. This would allow time for alternative plans. And at least users could prepare for it.Reserving many names so commonly used in software projects and then renaming projects with those names has many problems. For example - all links to the project are invalidated - Cross project Issue and MR references in git commits will be invalidated - Cross project Issue and MR references will be invalidated - Public repositories with external links will all be invalidated without hint of what happenedConsidering number of forced renames planned for gitlab.com and then adding all renames which will need to be done in private installations. This is huge change which will be done without notification. Especially as there would be alternatives.Since there is still time to change the plan. Would it be possible to have a gitlab comment on these alternative plans and hopefully prevent the renames?
We have a very consistent naming pattern for our projects so they are guessable. Now we have to rename our assets project because someone thought it was a good idea to restrict names you could call your own project? Can you imagine github telling us what we can't name our repo to? If you don't want the name of my project to affect your URL, then change your URL scheme so it can't. Don't force me to change my repo name. Officially registering my displeasure.
We have a very consistent naming pattern for our projects so they are guessable. Now we have to rename our assets project because someone thought it was a good idea to restrict names you could call your own project? Can you imagine github telling us what we can't name our repo to? If you don't want the name of my project to affect your URL, then change your URL scheme so it can't. Don't force me to change my repo name. Officially registering my displeasure.
@jason.rowland maybe I misunderstand you, but the renames would only affect the url.
Not the Project name. Nothing is keeping you from naming your project assets.
Or are you displeased because the url will change?
I ran the renaming script they provided which just appends a ‘0’ onto the end of the repo path. I did that because it was tested and simple and would let me back into the admin interface for the repo so that I could rename it to ‘asset’ more easily. so in the UI it still looks like api/assets. but you get to it at https://gitlab.xyz.io/api/assets0. and cloning is now git@gitlab.xyz.io:api/assets0.git
I guess I'm ignorant on what you mean by project name then, but i equated it to what i see in both the URL and the git clone command. I use the name to construct the URL and the git clone command. So to answer your question specifically, I guess I'm displeased with a url change not matching what my project is named and further confused now because I'm trying to think of a scenario where I would want urls to be different than what the name is.
I am looking through the release notes of 8.15, 8.15.1 and 8.15.2 and either I am blind or it really isn't mentioned anywhere that certain project names are now reserved. I understand that this is necessary for upcoming features like nested groups but why not mention this issue prominently in the release notes? Or better, offer a semi-automated way to rename affected projects if that is really the only possible solution? Getting a big 404 without any explanation when browsing to a project is obviously not great.
We got hit by this today; our profile Puppet module is now no longer accessible through our Gitlab web interface and I am currently struggling to find a new name for the project that doesn't totally clash with our naming conventions. The roles/profiles pattern is one of the cornerstones of successful Puppet deployments and I am guessing this issue affects many people hosting Puppet modules in Gitlab.
@antaflos at a first glance profile could be a word that can be allowed in project names. /profile is used by gitlab for the profile settings so we can't allow it for groups/users, but projects are probably ok.
(Don't take my word for this. Maybe I'm missing something important)
Can you imagine github telling us what we can't name our repo to?
its a technical reason, not because of good/evil intentions. Before we followed same structure with GitHub which is :namespace/:project. In order for it to work properly you need to reserve only :namespace names. As result you cant create group with name profile at GitLab or organization with name profile at GitHub.
Now we are going to introduce nested groups support (because it was highly requested by users). As result our schema can vary from :namespace/:project to :namespace/:namespace/:project. To ensure it works correctly we need to apply some restrictions on project name too.
So I don't see anything bad about restricting certain names. Bad thing is that we did not do it earlier and now some users got a painful transition.
@dzaporozhets Maybe it's too late but how about rename reserved names instead users projects e.g. by adding underscore to the beginning (_profile, _issues)? I think it will be more user friendly.
Maybe it's too late but how about rename reserved names instead users projects e.g. by adding underscore to the beginning
@akhnin Agree it would be nicer but If there are projects with name issues and _issues in same namespace (which is possible) - rename will fail. So we decided to use incremental suffix ( if issues0 is taken we use issues1 )
What happens to existing links already indexed by Google and other search engines? Are you doing a redirect?
@joshunger we do not automatically do redirect. If you have your own GitLab instance with popular public projects - we would recommend to add such redirect rules at nginx. If we are talking about GitLab.com - I think we can do same for some projects. But make sure your project is actually affected by rename first.
Just another 2ct - I came here after searching a lot for why I cannot name a repo "snippets". I think it's a rather bad idea to reserve and block (so many) commonly used words. For internal usage GitLab should use a special internal notation, but not limit users in naming repositories. I like the prefix proposal.
BTW, which alternative name would you recommend for "snippets"?