Support GitLab url with custom path

[gurobokum]

When gitlab is exposed on the path https://mydomain.com/gitlab cml cannot work with such types of urls - the generated api endpoint is https://mydomain.com/api/v4 but should be https://mydomain.com/gitlab/api/v4

Also it can be appropriate to support custom ports in the urls

[0x2b3bfa0]

Also it can be appropriate to support custom ports in the urls

As per the url documentation, it looks like we already support ports out of the box through the use of the host property instead of hostname for connections. (?)

[0x2b3bfa0]

@JIoJIaJIu, we can't reliably determine whether a path component is part of the base address or just belongs to a specific repository path, because the latter could contain subgroups with a variable number of path components:

https://gitlab.local:443/base-path-component/user-or-group/first-subgroup/second-subgroup/project

[0x2b3bfa0]

The most elegant solution I can think of would involve allowing users to specify the base and the repository path separately:

    cml-runner \
        --base "https://gitlab.local:443/base-path-component" \
        --repo "user-or-group/first-subgroup/second-subgroup/project"

We could keep backwards compatibility by requiring either both --base and --repo or just the latter if it matches /^https?:\/\// or similar.

[DavidGOrtega]

@0x2b3bfa0 subgroups should be supported as far as I remember 🤔

[0x2b3bfa0]

@DavidGOrtega, they are, but only when the GitLab root is the server root. When using https://mydomain.com/gitlab or similar, we don't have any way to determine if the /gitlab path component is part of the path or is the server root.

[DavidGOrtega]

I see, well this is a very specific set... I can imagine a solution... we could traverse the path asking for the api endpoint until we have it

[0x2b3bfa0]

I thought the same, but it seemed a bit hacky. Anyhow, it might actually be a good solution for this specific condition. We can skip the last two path components and start from the root in order to optimize the algorithm for the best case.

const path = '/gitlab/group/subgroup/user/project';
const components = path.split('/').filter(Boolean);

for (let index = 0; index <= components.length - 2; index++)
    console.log(components.slice(0, index).join('/'));

[DavidGOrtega]

We can skip the last two path components and start from the root in order to optimize algorithm for the best case

No really needed if the url is a proper gl setup it will break before the proposed condition. It could be all promisified to test all possible endpoints at once.

[DavidGOrtega]

What is the remote.origin.url that get @JIoJIaJIu and @0x2b3bfa0 anyone knows?

[0x2b3bfa0]

No really needed if the url is a proper gl setup it will break before the proposed condition.

Agreed: the suggested optimization would only matter for broken links, where we could return earlier.

It could be all promisified to test all possible endpoints at once.

That would be infinitely better, but would require the request function to accept a custom api_v4 variable on each invocation.

What is the remote.origin.url that get @JIoJIaJIu and @0x2b3bfa0 anyone knows?

❓

[0x2b3bfa0]

@DavidGOrtega, after a head-scratching session, I have been unable of using a promise to run every operation in parallel, because:

1. The class constructor function must be synchonous.
2. Promise.all would require a blocking await that is not possible.

Anyhow, ECMAScript is not my mother tongue and I might be missing something important. Do you know any elegant way of running asynchronous operations on a constructor without requiring users to call an additional initialization function or moving the awaiting code to methods?

[0x2b3bfa0]

Nevermind: solved through #464 with a bit of memoization and calls on each function two separate endpoint arguments (argh!)