Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support git+http #605

Closed
rndmh3ro opened this issue Oct 4, 2022 · 8 comments · Fixed by #958
Closed

Support git+http #605

rndmh3ro opened this issue Oct 4, 2022 · 8 comments · Fixed by #958
Labels
feature Feature missing according to gitlab ci standard

Comments

@rndmh3ro
Copy link

rndmh3ro commented Oct 4, 2022

Is your feature request related to a problem? Please describe.
I have a private gitlab-instance that has no ssh-access enabled. I have to clone/push/etc via https.

When using includes in my gitlab-ci.yaml, gitlab-ci-local tries to download these includes. The function downloadIncludeProjectFile uses git archive under the hood which does not work with https but only with ssh.

Describe the solution you'd like
I'd like to use includes with my instance that has no ssh enabled.

Describe alternatives you've considered

Additional context
I thought about doing it with curl or wget via the gitlab API like this:

    static async downloadIncludeProjectFile (cwd: string, stateDir: string, project: string, ref: string, file: string, gitData: GitData, fetchIncludes: boolean): Promise<void> {
        const remote = gitData.remote;
        const normalizedFile = file.replace(/^\/+/, "");
        try {
            const target = `${stateDir}/includes/${remote.host}/${project}/${ref}/`;
            if (await fs.pathExists(`${cwd}/${target}/${normalizedFile}`) && !fetchIncludes) return;
            await fs.mkdirp(`${cwd}/${target}`);
            await Utils.bash(`git archive --remote=ssh://git@${remote.host}:${remote.port}/${project}.git ${ref} ${normalizedFile} | tar -f - -xC ${target}`, cwd);
        } catch (e) {
            try {
              const target = `${stateDir}/includes/${remote.host}/${project}/${ref}/`;
              if (await fs.pathExists(`${cwd}/${target}/${normalizedFile}`) && !fetchIncludes) return;
              await fs.mkdirp(`${cwd}/${target}`);
              await Utils.bash(`curl --header "Private-Token: ${token}" -O ${target}/${normalizedFile} https://${fomain}/api/v4/projects/${project}/repository/files/${normalizedFile}?ref=${ref}`, cwd);
            } catch (e) {
            throw new ExitError(`Project include could not be fetched { project: ${project}, ref: ${ref}, file: ${normalizedFile} }`)
;
          }
        }
    }

Or maybe with axios? However I'm not proficient with javascript to include a working solution.

@firecow
Copy link
Owner

firecow commented Oct 4, 2022

We need a way to specify the ACCESS token...

Is it only fetching includes that fail?

I'm asking because I've never tried gitlab-ci-local without ssh access.

Possible workaround below.
https://gist.github.com/taoyuan/bfa3ff87e4b5611b5cbe

@firecow firecow added the feature Feature missing according to gitlab ci standard label Oct 4, 2022
@rndmh3ro
Copy link
Author

rndmh3ro commented Oct 5, 2022

I couldn't really test it further since it fails pretty early. Checking the code, remote variables will probably also fail:

> grep -r "git archive" src/
src/variables-from-files.ts:            const res = await Utils.bash(`git archive --remote=${url} ${ref} ${file} | tar -xO ${file}`, cwd);
src/parser-includes.ts:            await Utils.bash(`git archive --remote=ssh://git@${remote.host}:${remote.port}/${project}.git ${ref} ${normalizedFile} | tar -f - -xC ${target}`, cwd);
src/variables-from-files.js:            const res = await utils_1.Utils.bash(`git archive --remote=${url} ${ref} ${file} | tar -xO ${file}`, cwd);
src/parser-includes.js:            await utils_1.Utils.bash(`git archive --remote=ssh://git@${remote.host}:${remote.port}/${project}.git ${ref} ${normalizedFile} | tar -f - -xC ${target}`, cwd);

The workaround doesn't work for me..

@firecow
Copy link
Owner

firecow commented Oct 5, 2022

@rndmh3ro I need a little more info about the workaround.

What exactly did you put your global git config?

@rndmh3ro
Copy link
Author

rndmh3ro commented Oct 6, 2022

I put this in my config. example.com replaced with my internal gitlab server.

git config --global url."git@git.example.com:".insteadOf https://git.example.com/
git config --global url."git://".insteadOf https://

This doesn't work, because the problem is that git archive does not work with https in my gitlab instance (or in general with all gitlab instances?). So replacing ssh-access with https-access locally is not useful.

@firecow
Copy link
Owner

firecow commented Oct 6, 2022

Oh, I thought git archive would use those git instructions.
Well, in that case, we need a proper feature implemented to deal with the http case.

@firecow firecow changed the title Not working when ssh-access is disabled Support git+http Nov 18, 2022
@iutipikin
Copy link

Looks like Gitlab is not support git archive over https at all. @firecow can you please update readme's --fetch-includes section to mention explicitly what we need to use SSH only authentication?
I have a use case similar to @rndmh3ro and I spent a lot of time digging root case of non-fetched includes, as there is no error message. For some reason git output of fatal: operation not supported by protocol was not detected by try-catch.

@firecow
Copy link
Owner

firecow commented Dec 9, 2022

This is a dublicate

I shall explicitly warn users about git+http in the README.

Edit: it doesnt seem to be a dublicate, reopening.

Edit: I'm an idiot 🤣

@firecow firecow closed this as completed Dec 9, 2022
@firecow firecow added bug Something isn't working and removed feature Feature missing according to gitlab ci standard labels Dec 9, 2022
@firecow firecow reopened this Dec 9, 2022
@firecow
Copy link
Owner

firecow commented Dec 12, 2022

0aecd8b

@firecow firecow added feature Feature missing according to gitlab ci standard and removed bug Something isn't working labels Feb 25, 2023
firecow added a commit that referenced this issue Aug 17, 2023
* Enabled download of includes over HTTP

* Added option --git-over-http (default: false)
* When active: Include-Parser uses git spare-checkout instead of git archive

* fixed linter problems

* autodetecting whether sparse checkout should be preferred

* CLI option still available but hidden

* Removed CLI option regardin sparse checkout

* only auto-detection left over

* refactored: parser-includes relies only on git-data

* refactored: git-data detects schema on basis of firecow's proposed regexp

* fix/workaround: test on invalid project includes passes now

* The test attempted to compare an expected error text
  with the assertion error's message.
* The assertion error's message might have changed previously,
  so the test failed
* Analysis of the current logs of failing tests in the pipeline
  shows that different reasons might lead to an expected failure
  when calling 'git archive':
    * the server doesn't exist or isn't reachable (which could timeout), then error message contains
      - ssh: Could not resolve hostname <non-existing-hostname>: Name or service not known
      - fatal: the remote end hung up unexpectedly
    * the credentials for the server are wrong, then error message contains:
      - git@gitlab.com: Permission denied (publickey).
      - fatal: the remote end hung up unexpectedly
    * the repository doesn't exist on the server, then error message contains:
      - ERROR: The project you were looking for could not be found or you don't have permission to view it.
      - fatal: the remote end hung up unexpectedly
    * the file doesn't exist on the server, then error message contains:
        => remote: fatal: pathspec '.gitlab-modue.yml' did not match any files
* Thus it seems OK to test against the 'fatal.*' only

* preparing back-merge as discussed with firecow

* using clearer if clauses for schema default ports

* fixed target path for tar call

---------

Co-authored-by: docdnp <dimitri.papoutsis@gmail.com>
Co-authored-by: Mads Jon Nielsen <madsjon@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Feature missing according to gitlab ci standard
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants