Closed anbraten closed 1 year ago
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
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:
.../repoId
without a second slash => use that id.../repoOwner/repoName/
yes for API we can just completly switch to ID but we need a ID lookup then ...
Ahh, so some endpoint to search / lookup a repo?
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.
@hasafox the summary is asap this issue here got resolved
@hasafox the summary is asap this issue here got resolved
Thanks.
It seems like this is atleast partially fixed by #1078. What more needs to be done here to get this past the finish line?
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
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 😅
Haha thanks for the explanation!
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
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
We currently use the repository owner and repository name in api calls and in the UI as part of the url:
Although this is nice for humans it has some limitations:
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.