GIT not being recognised inside docker build inside gitlab

[augustocdias]

Hi,

I couldn't find the reason but I have a project that the GIT consts are all set to none when built inside gitlab ci.
I run the build in a rust:alpine based image.
I've tried to print out all the info I could and couldn't find any reason for it to fail:

• The cargo manifest path is pointing to the root of the project
• I've printed the folder structure and the .git directory was in the root folder
• I've printed the output file from built and it is indeed setting the git consts to None
• I've added git2 dependency as a build dependency and called Repository::discover(&Path::new(env!("CARGO_MANIFEST_DIR"))) to see if it was failing but it was returning Ok(repo).
• I have a project with the following structure

|_ build.rs -> I call built here
|_ Cargo.toml -> here I have a workspace config + the dependencies from the root project
|_ src
|___ main.rs
|___ build_info.rs -> the generated code is appended here
|_ crate1
|___ Cargo.toml
|___ src
|_____ lib.rs
|_ crate2
|___ Cargo.toml
|___ src
|_____ lib.rs

I have another project that has a simpler structure that everything works as expected. So I imagined it could be something related to my project structure, but I have no idea what could it be.

[lukaslueg]

This is (as I now realize) undocumented, but expected behavior:

built/src/lib.rs

Lines 421 to 429 in c7b082b

	#[cfg(feature = "git2")]
	fn write_git_version(manifest_location: &path::Path, w: &mut fs::File) -> io::Result<()> {
	// CIs will do shallow clones of repositories, causing libgit2 to error
	// out. We try to detect if we are running on a CI and ignore the
	// error.
	let (tag, dirty) = match util::get_repo_description(&manifest_location) {
	Ok(Some((tag, dirty))) => (Some(tag), Some(dirty)),
	_ => (None, None),
	};

libgit2, which is used to retrieve git-information is unable to query repositories that are based on shallow clones. This has been a long-standing issue which we can do nothing about I'm afraid.

[augustocdias]

Okay... I understand why it doesn't work... But now I ask why it works in my another project that runs in very similar conditions (same gitlab ci and almost identical stage config)? And why when I call Repository::discover myself in the build.rs it works?

[lukaslueg]

Probably because the other repo has a shorter commit history and its root is within the commit-depth that GitLab's CI will check out.

You may be able to tell GitLab's CI to do a full (non-shallow) checkout.

[augustocdias]

Gitlab set the depth to 50 by default and what you said is not the case. The other project is older and contains a lot more commits. This project is new and probably doesn't even have the 50 commits to limit the depth

[lukaslueg]

Then I don't know.

[FelixZY]

+1 on the "cannot get git features to work inside docker", although I understand why.

I think it would be nice if there was a way to provide the git variables manually - e.g. for CI and docker builds. These variables are often available but not in the "traditional" .git/ sense.

Perhaps this could be expanded into an even more generic feature - it would be nice to be able to provide other constants to the built.rs file as well, or replace existing ones, via build.rs.

[lukaslueg]

@FelixZY, are you referring to "inside docker" in general or gitlab specifically? I'm not aware of a docker-related problem in general.

[FelixZY]

I might be hijacking the issue a bit here but I'm referring to the fact that you cannot retrieve git information if, for some reason, you are stuck with a non-regular clone. In my case, I have access to the full repository but since I want to build a subdirectory (monorepo) in docker, I lose my git context (which is completely reasonable).

In this case, I want to be able to provide the "lost" information manually, e.g. via an environment variable or by calling the write_variable macro myself in build.rs. This seems like a feature which would help alleviate the OP's issue as well.

I'm therefore suggesting two distinct features:

1. The ability to include certain environment variables in built.rs. This could be done by adding variables with a BUILT_ prefix` .
2. The ability to add or replace variables from build.rs. This could e.g. take the form of a macro set_variable!("GIT_COMMIT_HASH_SHORT", "Option<&str>", "abc1234").

If 2. is implemented, 1. probably isn't necessary as developers could easily implement the functionality themselves.