CARGO_GIT_WRAPPER variable and GITLAB cicd scripts

[duaneellissd]

I think you would call this a "feature request"

I need a means to force CARGO to use a script wrapper for all GIT operations.

We already gave up on "libgit2" - it does not work in our environment we already use the: git-fetch-with-cli feature as a standard workaround to make anything with GIT work.

What I think I need/want and I am suggesting is this:

For example cargo has this existing ENV variable it supports.

RUSTC_WRAPPER — Instead of simply running rustc

Perhaps what is required is this:

CARGO_GIT_WRAPPER - instead of simply running 'git' - run this command

I do not see anything like it on the Cargo ENV document page:

Environment Variables - The Cargo Book

The specific problem is this:

During normal use - ie: me typing cargo commands etc - Cargo can use the standard GIT command line tool.

In that case - git can access my ssh keys, the URL is correct etc. THUS - cargo can pull crates from our GIT REPO in the normal way using a git/ssh based URL.

HOWEVER - in the GITLAB CI?CD process the GITLAB RUNNER provides an HTTP session token to fetch from the GITLAB Server. That URL is very different.

Our other tools have "git url rewriters" that trigger off of the GITLAB runner variables like: CI=true and rewrite GIT URLS as needed.

Effectively this means I require two different URLS in the Cargo.toml file -

• Url #1 the SSH based URL when we are not in the CI/CD operation and
• URL #2 An HTTPS based when we are in the GITLAB CICD operation.

That URL#2 is a HTTPS + CI_TOKEN based URL that only works under that specific CI session (the token expires at the end of the CI Pipeline)

I believe the easy means to solve this is in a script

Before you suggest it: I know that GIT has rewrite (instead of?) rules that help - but these are unique to the user and need to be only used if and only if we are in the CI?CD situation (ie: Gitlab provides a number of CI/CD environment variables)

The only work around I think I can do for now is the following - and it is nasty. Hence this suggestion/feature-request.

a) In my GITLAB CI script - insert a SHIM directory in the front of my ${PATH}, before executing "cargo build" or "cargo test" - that SHIM directory would have a "git" replacement script - that rewrites the URL..

b) That script would then remove its directory from the PATH (without the SHIM dir) and re-execute the normal GIT command with the updated/edited URL.

Ugly.

[kornel]

You don't need to modify git for this. It already has functionality required by GitLab built in.

git config --global url."https://gitlab-ci-token:${CI_JOB_TOKEN}@${CI_SERVER_HOST}".insteadOf "ssh://git@${CI_SERVER_HOST}"

You can also configure a credential helper in git.

[duaneellissd]

I do not think that is possible.

Are you suggesting that I run "git config" - like that as a command in every ci/cd script? Really?

Concern #1 - The GITLAB RUNNER user is not a normal user, thus there is no place to save that global configuration?, ie: it effectively runs as a restricted user right?

Concern #2 - Even if it was saved, This would create a NEW 'insteadof' option every time a cicd session would run, after a few thousand pipelines that configuration file would need to be "cleaned up" right?

Concern #3 - The command you are specifying is going to write to a "non-existent" GIT configuration file that is not persistent.

Concern #4 - "Where would the credential helper" information be stored? The GITLAB RUNNER is a non-existing person (this is a variation of the concerns above)

[kornel]

Gitlab expects such things to be set up in the base build image.

Or you can use before_script and extends or YAML anchors or references to copy setup for individual jobs. There are also includes and components to dedupe such code across projects.

You'd need to do the same things to set up the wrapper command anyway (which BTW you already can by manipulating PATH).

Usually jobs run in a disposable environment, so there's nothing to clean up. You can also make a copy of the config, and redirect to it with GIT_CONFIG_GLOBAL.

I find Gitlab CI to be clunky and act like it's intentionally obtuse sometimes, but the problem it inflicted on itself is already fixable within it too.