Allow specifying custom remote name instead of `origin`

[yutotakano]

Is your feature request related to a problem? Please describe.

Many of my local repositories don't have an origin remote, as I prefer to be explicit especially when working with forked projects.

For example, for one project I have the following remotes:

• upstream
• upstream-myfork
• vendored
• vendored-myfork

These allow me to explicitly choose whether I'm pushing my changes to a vendored variant of an OSS project, or the upstream OSS project itself, or any of its forks which I have push access to. I avoid origin because it's mentally ambiguous and can lead to accidental pushes to the wrong repository.

However, gitlab-ci-local seems to hardcode origin as the name of the remote:

Unable to retrieve default remote branch, falling back to `main`.
  The default remote branch can be set via `git remote set-head origin <default_branch>`
Using fallback git remote data

Describe the solution you'd like

I'm not 100% sure what the remote name is used for, but if it's absolutely necessary, I would like to pass a flag to gitlab-ci-local to choose the remote name manually.

Describe alternatives you've considered

Some automatic method to grab the most accurate remote name from the current branch (e.g. by retrieving the tracking remote for a branch) could be nice, but would fail in the case where a branch doesn't track anything remote.

Additional context
N/A

[josephvoss]

From hitting something similar today, the remote branch is used to evaluate any changed files if you have job definitions that use the "changes" rule. Instead of origin you can define a custom remote gcl-origin and use that for checking your changes against.

gitlab-ci-local/src/git-data.ts

Lines 95 to 97 in 679e8af

	// NOTE: For power user that wishes to customize the remote url
	const res = await Utils.spawn(["git", "remote", "get-url", "gcl-origin"], cwd);
	gitRemote = res.stdout;

+1 that this should be able to be set as a flag though.

[yutotakano]

Nice find @josephvoss , thank you very much for it! That's actually enough for me to work around my specific problem, but definitely will keep this issue open - a flag to customise it per every call/branch would be much better.