Access projects by their id

[anbraten]

We currently use the repository owner and repository name in api calls and in the UI as part of the url:

https://ci.woodpecker-ci.org/woodpecker-ci/woodpecker
https://ci.woodpecker-ci.org/api/repos/woodpecker-ci/woodpecker/branches

Although this is nice for humans it has some limitations:

• Gitlab has support for nested repositories / sub-projects which would require multiple levels #648
• Woodpecker is limited to a single remote as the remote is currently not part of the url and therefore it currently can not by design support multiple forges at once #138

Current proposal

Refactor the UI and api urls to use the id of the Woodpecker project instead.

Problems

This would be a breaking change and we would need to thing about adding redirects.

[6543]

I like to still be able to access via rep-slug ... so we might wana do something similar to what gitlab does ...

first interprete it as repoOwner/repoName and if notFound then it's an id

[anbraten]

Yeah, using the repo slug is pretty nice in general. For api I would guess its fine to always use the id?

For the UI it could do the following:

• check if the url has a syntax like .../repoId without a second slash => use that id
• check if the url has a syntax like .../repoOwner/repoName/
  • if so use the first configured forge from the list and get the repo based on the slug
  • maybe redirect to the id version?

[6543]

yes for API we can just completly switch to ID but we need a ID lookup then ...

[anbraten]

Ahh, so some endpoint to search / lookup a repo?

[haxung]

Could someone tell me when woodpecker support subgroups project(e.g. gitlab.com/A/B/test.git)? I used woodpeckerci/woodpecker-server:next but It doesn't support this feature.

[6543]

@hasafox the summary is asap this issue here got resolved

[haxung]

@hasafox the summary is asap this issue here got resolved

Thanks.

[vanceism7]

It seems like this is atleast partially fixed by #1078. What more needs to be done here to get this past the finish line?

[qwerty287]

1078 was about the backend communicating to the forge, this issue is about the UI.

[vanceism7]

Ohh gotcha. If someone could point me in the right direction/which files need to be touched, I could try working on this. I'd like to see this feature land so I don't have to lose my subgroups in gitlab lol

[anbraten]

You basically have to adjust all the api endpoints to use a /repos/:projectID instead of /repos/:owner/:name and then load the project inside the endpoint functions by its id. After that you have to adjust the UI client the same way (api-client & router). And at the end we need a new endpoint like /repos/lookup/:owner/:name in case someone accessed the UI by the repo-name to redirect the user to the same url in the UI but using the id, so https://ci.woodpecker-ci.org/woodpecker-ci/woodpecker/settings would be redirected to https://ci.woodpecker-ci.org/project/123/settings. I think that would already be a good start, but also quite some refactoring 😅

[vanceism7]

Haha thanks for the explanation!

[renothing]

maybe a new path level would be a nice resolution, especially consider federation will be available soon for gitea. so that means multiple gitea providers can be connected to a single woodpecker.

for example /<provider id>/repoOwner/repoName

The advantage of this is that the API can be changed as little as possible and can be backward compatible

[anbraten]

I changed it in #1691 already to use ids which seems to be working quite fine. This way multiple forges and also repos with nested owners owner/sub-owner/repo/... like gitlab is supporting it are both working. For compatibility the current owner/repo/... routes in the UI are simply redirecting towards the new repo-id/.... routes