Add function to checkout the jobs repository

[ColinKinloch]

This branch adds crate::clone_git_repository to clone git repos generally and Job::clone_git_repository to clone specifically defined by the gitlab job.

clone_git_repository is heavily based on PrepareFetch::fetch_only

Since the gitoxide PrepareFetch and PrepareCheckout structs delete the target path when they are dropped I opted to checkout the repository to a temporary directory, then move it's contents to the path provided to the target directory.

This adds a rather unwieldy GitCheckoutError enum. gitoxides Error types triggers the result_large_err clippy warning.

This requires rust version 1.73.0 or later.

Fixes #21

[andrewshadura]

This looks okay, but I haven’t gone deeply into details. I trust you tested this code well? (It would be great if it also included some automated tests.)

[refi64]

I don't think this is viable without either async or cloning in a separate thread (which would make cancellation really tricky, though you seem to have some interrupt-related stuff wired up already); blocking an entire I/O thread for what might be a very long clone process is not workable. Should this maybe just be using libgit2 or something else instead?

[sjoerdsimons]

fwiw i'd prefer to stay with gitoxide to avoid more C dependences in the core of gitlab-runner. But yes it should be done in a dedicated thread if there is no async api

[ColinKinloch]

I've updated it to use tokio::task::spawn_blocking which runs it on a different thread.
I used a CancellationToken and tokio::select to trigger gitoxide to interrupt, CancellationToken is already used in the gitlab-runner-rs API so hopefully is okay.
gitoxide re-exports Progress from the prodash crate to allow the caller to monitor progress. Is that something we should do?

[refi64]

this is a bit tricky to understand out-of-context, might want to add a few more details for some of these points

[refi64]

thought: if the goal is just to be able to read files from the repo, do we need to do an entire checkout to begin with? couldn't it clone a bare repo and then load files as-needed from there? though the apis might be harder to make for that...but it would likely also be a lot faster.

[sjoerdsimons]

Fwiw i wouldn't mind this being a potential future update ; I'm not sure how much faster it would be ("likely be a lot of faster" is always a dangerous statement in the land of optimisation). I guess it primarily depend on what work would be saved, which i guess is primarily unpacking the pack file.

Regardless; the time would be comparable to a normal checking in a normal gitlab runner (or faster as iirc gix is faster at this point then git).

[Copilot]

Pull Request Overview

This PR implements Git repository cloning functionality for the GitLab runner by adding two main functions: clone_git_repository for general Git repository cloning and Job::clone_git_repository for job-specific cloning. The implementation leverages the gitoxide library and includes comprehensive error handling through a new GitCheckoutError enum.

Key changes:

• Adds comprehensive Git cloning functionality with support for refspecs, depth control, and SHA-specific checkout
• Implements proper error handling for Git operations with detailed error categorization
• Provides both async and sync interfaces for Git operations with cancellation support

Reviewed Changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
gitlab-runner/src/run.rs	Fixes error message for build directory creation
gitlab-runner/src/lib.rs	Adds core Git cloning functions and comprehensive error handling
gitlab-runner/src/job.rs	Implements job-specific Git repository cloning method
gitlab-runner/src/client.rs	Defines Git information structures and error types
gitlab-runner/examples/demo-runner.rs	Adds example commands for testing Git functionality
gitlab-runner/Cargo.toml	Updates dependencies and adds gitoxide library

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

Using NonZeroU32::new will return None for depth value 0, but depth 0 should be valid for unlimited depth. Consider using a separate check or handling depth 0 explicitly.

Suggested change

	if let Some(depth) = depth.and_then(NonZeroU32::new) {
	fetch = fetch.with_shallow(remote::fetch::Shallow::DepthAtRemote(depth));
	match depth {
	Some(0) => {
	// Depth 0 means unlimited depth; do not set shallow clone.
	}
	Some(d) => {
	if let Some(nonzero_depth) = NonZeroU32::new(d) {
	fetch = fetch.with_shallow(remote::fetch::Shallow::DepthAtRemote(nonzero_depth));
	}
	}
	None => {
	// No depth specified; do not set shallow clone.
	}

[Copilot]

[nitpick] The function returns the temporary directory path, but the calling code is expected to move its contents manually. Consider returning the final destination path or handling the move operation within this function to improve the API design.

[Copilot]

[nitpick] The SHA is always passed as Some(), but the generic clone_git_repository function expects Option<&str>. Consider whether this should handle cases where SHA might be empty or invalid.

Suggested change

	Some(&self.response.git_info.sha),
	if self.response.git_info.sha.is_empty() {
	None
	} else {
	Some(&self.response.git_info.sha)
	},

[Copilot]

Using std::fs::rename to move a directory may fail across filesystem boundaries. Consider using a recursive copy operation or std::fs::create_dir_all followed by moving individual files.