You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had an idea of forking the NGitLab project and adding context-aware URL getters similar to what you can find in Octokit.
This would essentially use the existing data you provide for any API requests to get an object, to provide these URLs.
If I make a GitLabClient, then request, say, an issue or merge request, the context of what I'm asking for is passed onto the returned object, so you can simply use mergeRequest.BrowserUrl (or something similar) to embed the base server url + project id + sub paths to the object.
A simpler implementation would be to expose the ProjectId on each ISomethingClient, and we can write the URL construction logic ourselves.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Hello!
I had an idea of forking the NGitLab project and adding context-aware URL getters similar to what you can find in Octokit.
This would essentially use the existing data you provide for any API requests to get an object, to provide these URLs.
Take my usage: https://git.ryujinx.app
If I make a
GitLabClient, then request, say, an issue or merge request, the context of what I'm asking for is passed onto the returned object, so you can simply usemergeRequest.BrowserUrl(or something similar) to embed the base server url + project id + sub paths to the object.A simpler implementation would be to expose the
ProjectIdon eachISomethingClient, and we can write the URL construction logic ourselves.Beta Was this translation helpful? Give feedback.
All reactions