semantic-release
Add the option to specify the target project via project id
My main repo is in bitbucket, and the CI/CD runs there in a bitbucket pipelines, but my client has it's own git repo which mirrors mine, and when I "release" a new version, I just push into their GitLab.
When semantic-release runs in my bitbucket pipeline, I am pushing to my client's GitLab using this custom plugin I wrote: https://github.com/tomerh2001/semantic-release-gitlab-merge-request, but then I also want to create a GitLab release right after
Their gitlab is hosted at a specific URL, and the target project has a different ID then the one the CI runs in, so it would be great if we could specify a target project ID (and possibly the branch from the target) for the release
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?
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
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.
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_URLorGITLAB_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
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_URLorGITLAB_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.
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_URLorGITLAB_PREFIX.Looking at the code @JonasSchubert referenced, wouldn't setting the env var
CI_PROJECT_PATHsolve 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).