Add the option to specify the target project via project id

[tomerh2001]

Add the option to specify the target project via project id

[travi]

i dont think i understand the request here. it sounds like your desired workflow is outside the normal expectation of what this gitlab plugin was designed for. since you have already built a plugin related to your workflow, i'm wondering why you wouldnt just handle the additional need you describe directly from within your custom plugin. could you help me understand what i am overlooking?

[tomerh2001]

Ideally for separation of concerns. I don't want my plugin to try to do too much, just a merge request, nothing else + while this plugin already exists and is 250+ star battle-tested.

I just need to be able to specify the target repo using the project ID, instead of having it try to infer the target based on the current repo, which for a plugin that aims to be the generic semantic-release Gitlab deployment doesn't sound too weird of a request

I.E. just an optional PROJECT_ID parameter

[fgreinacher]

The workflow is indeed a bit special, but I think allowing to pass a project ID would be symmetrical to the existing possibility to pass a GITLAB_URL or GITLAB_PREFIX.

[JonasSchubert]

The workflow is indeed a bit special, but I think allowing to pass a project ID would be symmetrical to the existing possibility to pass a GITLAB_URL or GITLAB_PREFIX.

Sounds like a valid option. The function get-repo-id couldbe adjusted and it could be allowed to provide a GITLAB_PROJECT_ID or similar

[tmeijn]

The workflow is indeed a bit special, but I think allowing to pass a project ID would be symmetrical to the existing possibility to pass a GITLAB_URL or GITLAB_PREFIX.

Looking at the code @JonasSchubert referenced, wouldn't setting the env var CI_PROJECT_PATH solve this then? It seems to first try to infer from that variable and as a fallback the git url.

[fgreinacher]

The workflow is indeed a bit special, but I think allowing to pass a project ID would be symmetrical to the existing possibility to pass a GITLAB_URL or GITLAB_PREFIX.

Looking at the code @JonasSchubert referenced, wouldn't setting the env var CI_PROJECT_PATH solve this then? It seems to first try to infer from that variable and as a fallback the git url.

Only partially, because it'll only be evaluated when running within GitLab CI (the service === "gitlab" condition).