Marcos de Oliveira opened 2 years ago
|
|||||
As OneDev evolves, reserved names will expand, and this may conflict with existing project names. Also id will not change even if project is renamed/moved/archived etc. |
|||||
I see... Maybe there is a way to do some fuzzy search to match and redirect to the repo ID then, instead of returning 404 directly? My point is that there should be a way to link to a repository by name so people know what they are accessing beforehand. Also, being able to go to a repo by URL would be nice. |
|||||
This turns out to be difficult with Wicket (web framework used by OneDev) as it expects fixed segments for pages. Since project path now contains arbitrary number of path segments (/project1/child1/child2 etc), it breaks url routes of OneDev pages. The only possible way is to encode path separator |
|||||
Robin Shen changed state to 'Closed' 2 years ago
|
|||||
Sorry for bumping closed issue but - does the structure has to be reflected in the URL? It seems that with ID the structure is not included in the URL, and having uniquely named projects (possibly in user scope?) would mean that something like http://onedev-server/user|org/project/issue|build|etc. could be possible? |
|||||
It is rather difficult, since project can be nested multiple levels. And this means that there are ambiguous if project name is used in path, for instance, for |
|||||
I'm not exactly sure I understand your message and example above. I think the misunderstanding comes from the constrain I was thinking of - basically project names would be unique globally (or within user/organisation, along the line of GitHub's notion of |
|||||
I mean if you have two projects We can of course to not allow OneDev projects to use reserved names such as Another approach is to prefix all internal url segments with some special character, for instance: http://server/myproject/~issues http://server/myproject/~settings But this seems to me more ugly than using project number. |
|||||
I think that using slash ( |
|||||
OneDev projects can nest child projects to form a path like structure. |
|||||
I'm aware of that but from what I can see it looks like the project-id is always from the selected project, i.e. https://<our_server>/projects/31 (parent project) list the child projects and one of them is for example https://<our_server>/projects/11. I see nowhere in the URL parent/child relationship. Even on this instance you have https://code.onedev.io/projects/392 which list 2 child projects and then child project is just https://code.onedev.io/projects/395 and NOT https://code.onedev.io/projects/392/395 (that would be ttps://code.onedev.io/projects/sierra and https://code.onedev.io/projects/sierra/onedev-server) |
|||||
This is because I am using project id to represent project. If you want to use project name, you will need to specify all parent project names along with current project name like |
|||||
Circling back to my previous argument: you can simply make project names unique, either globally or within user/organisation scope (which then should be included in the URL). I'd even argue that having unique project names would be somewhat helpful to avoid confusion as to which project are you using... |
|||||
That will be too limited. Even with that, you still need to make sure it does not conflict with reserved names such as issues, settings, etc. |
|||||
Why it would be too limited? I'd argue that having two projects with same name would be quite confusing. Same goes for allowing project names with reserved names (e.g. creating project named "settings") |
|||||
We ourselves have many projects of same name. For instance: projectA/production, projectB/production, etc. Also when forks a project, OneDev creates sub project of same name under a project named by user account. Forcing project names to be unique in a tree structure is really a bad idea to me. |
|||||
OK, but you still differentiate between organisation/user (projectA/projectB seems like organisation) and also on the username basis (which is quite natural for forks and works as such under github/gitlat/gitea AFAIR). For this reason I was arguing that unique project name within organisation/user account indeed seems logical - would you have two projects like projectA/production and projectA/production (with different id so in current implementation it would be code/onedev.io/projects/160 and code/onedev.io/projects/161)? |
|||||
There is no built-in organization/user concept to organize projects in OneDev. It is just a convention to create a parent project with same name as the user forking the project, and then place the forked project under that parent project. Every project in OneDev is using the same object type, and this has tremendous advantages as you can nested them in multiple levels, and child projects can inherit settings from parent project... |
|||||
The clone functionality identifies the repository by name, couldn't an automatic redirect be implemented? For example: |
|||||
OneDev can easily identify the clone connection out of web connection, and clone url only has one format: http://server/path/to/project. There is no ambiguity here. |
|||||
Nitpick, k8s documentation (https://code.onedev.io/projects/162/files/5.0/pages/deploy-into-k8s.md) still uses project name in the url (https://code.onedev.io/projects/onedev-server/builds?query=%22Job%22+is+%22Release%22) which returns an error... I would still argue that you can still have parent/child (and inheritance of projects) without ambiguity in links in the same manner that you can have project name in git clone links. |
|||||
This doc is outdated. OneDev now deploys into k8s via helm. |
|||||
That wasn't the point - the point was it used project name in the URL and it would work. |
|||||
That is because in that release, OneDev projects do not support to be organized in a tree structure yet. |
|||||
I would like to go back to this issue and revise it. I understand the motivation (multi-level project grouping) but... it's less readable and simply doesn't work beyond simple nesting. I just imported some projects and decided to take advantage of the more complicated project structure. In the end it was Result:
I would say that simplifying grouping (having only notion of scopes, like user or organization) would be more than sufficient and probably would help avoid issues like above.
What's more, linking and cloning would be more informative - user would know that link |
|||||
None of the issues you are encountering exists at my side with 7.5.1. |
|||||
Possibly issues were caused by https://code.onedev.io/projects/160/issues/923 However, I would like to circle back to the main topic here - using project names to access them. We currently have multi-level projects. Those projects use You had two suggestions previously:
I think that (2) would be more than enough and having That would also "fix" problem mentioned in server#923 with inflated project-ids after failed import and re-import - those IDs wouldn't be visible anymore. tl,dr; Prefixing internal 1dev pages ( |
|||||
That's a very good approach, IMO. I didn't even thought about prefixing internal pages, I think that's the real fix and something that GitLab does, although, slightly differently, as they prefix internal pages by '/-/'. Something like https://code.onedev.io/ondev/-/issues and https://code.ondev.io/onedev/server/-/issues might be feasible. |
|||||
That is not really an option because the list could contain words that conflict with already existing projects. This would break during upgrade unless you automatically rename these projects. Prefixing internal pages is also only an option if the prefix character sequence is currently disallowed in project names. So |
|||||
Thanks for all your input. Will explore the option of prefixing internal pages with special character. |
|||||
Robin Shen changed state to 'Open' 2 years ago
|
|||||
Awesome, thanks! |
|||||
Thank you, Robin! Is there an (related) issue that could be tracked? |
|||||
Issue reopened. Just use this to track. |
|||||
OK, thank you :-) |
|||||
OneDev changed state to 'Closed' 1 year ago
|
|||||
State changed as code fixing the issue is committed |
|||||
OneDev changed state to 'Released' 1 year ago
|
|||||
State changed as build #3146 is successful |
|||||
Thank you very much! |
|||||
Great, thank you Robin! |
|||||
Seems like emails are not using the new URL format yet. On a related note, trailing slashes cause an error. Example: https://code.onedev.io/onedev/server/ |
|||||
@davidebeatrici the trailing slash issue has been fixed in build #3149 As to email not using new url format, can you please share a screenshot? |
|||||
Looks like it's fixed now, the email I received as notification for your message uses the new format. |
|||||
Hi there, and thanks for the effort taking back to us the pretty URLs :) I’m a bit concerned about the fact that it’s a breaking change for all the links over the interwebs pointing to the old urls schema. Basically if I update my OneDev instance I must modify all the external links to my projects because the old /projects/$id paths will return a 404. I’ve something like ~1400 projects linked basically everywhere ?? (and not all the links are in a place maintained by me). Could you be so kind as to provide a programmatic url rewrite (or a 301 redirect at least) to maintain backwards compatibility? Thank you (: |
|||||
@crash I understand the situation, will try to make old urls working also in next one or two releases. Please watch issue #1008 to get notified. |
|||||
Thanks Robin, very appreciated! absolutely no rush, take all the time you need for that. I’ll post some of my considerations about it on the issue #1008 cheers, crash |
Type |
Improvement
|
Priority |
Normal
|
Assignee |
After introducing the repository chaining feature, we could not access repositories by their names anymore. I think the current behavior is because of parent project's URLs (issues, branches, commits, etc). But maybe you could introduce some reserved words for repository names to avoid collisions and use internal routes to access the child repositories panels by URI.