I've been trying to track down an issue with the GitLab CI Runner:
https://gitlab.com/gitlab-org/gitlab-runner/issues/3497
Note that I'm using "git version 2.7.2.windows.1".
I've narrowed it down to an observation that the [http] config seems
to be ignored by 'git submodule update'. Shouldn't those options be
respected by submodules?
Given a .git/config file like this:
------------------------------------------------------------------------
[fetch]
recurseSubmodules = false
[http "https://gitlab.exmaple.com"]
sslCAInfo =
C:\\Users\\gitlab-runner\\builds\\deadbeef\\0\\somegroup\\someproj.git\\CA_SERVER_TLS_CA_FILE
[core]
...
[remote "origin"]
url = https://jreinhart:<private-access-token>@gitlab.example.com/somegroup/someproj.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[submodule "some-lib"]
url = https://jreinhart:<private-access-token>@gitlab.example.com/somegroup/some-lib.git
------------------------------------------------------------------------
...I see the following results:
------------------------------------------------------------------------
C:\Users\jreinhart\testrepo>set GIT_CURL_VERBOSE=1
C:\Users\jreinhart\testrepo>git fetch
...
* Connected to gitlab.example.com (x.x.x.x) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: C:\Users\gitlab-runner\builds\deadbeef\0\somegroup\someproj.git\CA_SERVER_TLS_CA_FILE
CApath: none
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* <certificate details here>
* SSL certificate verify ok.
...
C:\Users\jreinhart\testrepo>git checkout master
C:\Users\jreinhart\testrepo>git submodule update --init
...
* Connected to gitlab.example.com (x.x.x.x) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
CApath: none
* SSL certificate problem: unable to get local issuer certificate
...
------------------------------------------------------------------------
Note that the CAfile reverted to its default instead of using the same
one from the `git fetch`.
Thanks in advance,
Jonathon Reinhart
+cc: Stefan, who has been looking at fetch --recurse-submodules recently
Hi,
Jonathon Reinhart wrote:
I've narrowed it down to an observation that the [http] config seems
to be ignored by 'git submodule update'. Shouldn't those options be
respected by submodules?
Given a .git/config file like this:
------------------------------------------------------------------------
[fetch]
recurseSubmodules = false
[http "https://gitlab.exmaple.com"]
sslCAInfo = C:\\Users\\gitlab-runner\\builds\\deadbeef\\0\\somegroup\\someproj.git\\CA_SERVER_TLS_CA_FILE
[...]
C:\Users\jreinhart\testrepo>set GIT_CURL_VERBOSE=1
C:\Users\jreinhart\testrepo>git fetch
[...]
* CAfile: C:\Users\gitlab-runner\builds\deadbeef\0\somegroup\someproj.git\CA_SERVER_TLS_CA_FILE
[...]
C:\Users\jreinhart\testrepo>git checkout master
C:\Users\jreinhart\testrepo>git submodule update --init
[...]
* CAfile: C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
[...]
Note that the CAfile reverted to its default instead of using the same
one from the `git fetch`.
Interesting.
The context is that "git submodule update" is simply running commands
like "git fetch" inside the submodules, and the repository-local
config of the superproject does not apply there.
In the long run, commands like "git fetch --recurse-submodules" may
chaange to use a single process. It's possible that some of the
repository-local configuration of the superproject would apply at that
point, though the inconsistency would be confusing, so probably not
these particular settings. Anyway, that's a faraway future; today,
"git fetch --recurse-submodules" is also running "git fetch" commands
inside the submodules, and the repository-local config of the
superproject does not apply there.
Would it work for you to put this configuration in the global config
file ("git config --global --edit")? That way, it would be used by
all repositories. If you want it only to apply within the testrepo
directory, you can use conditional includes --- something like:
in $HOME/.git/config/testrepo-ca:
[http "https://gitlab.example.com"]
sslCAInfo = ...
in $HOME/.git/config/git:
[includeIf "gitdir/i:~/testrepo/**"]
path = testrepo-ca
Thanks and hope that helps,
Jonathan
Thanks Jonathan.
The confirmation that the super-project config does not apply to the
submodules is what I was really looking for. We'll go from here.
This is a bit complicated, because this config is all generated
dynamically by the GitLab CI Runner when it is setting up a build job.
(See the linked issue in my first email for the gory details).
Thank you,
Jonathon
+cc: Stefan, who has been looking at fetch --recurse-submodules recently
Hi,
Jonathon Reinhart wrote:
quoted
I've narrowed it down to an observation that the [http] config seems
to be ignored by 'git submodule update'. Shouldn't those options be
respected by submodules?
Given a .git/config file like this:
------------------------------------------------------------------------
[fetch]
recurseSubmodules = false
[http "https://gitlab.exmaple.com"]
sslCAInfo = C:\\Users\\gitlab-runner\\builds\\deadbeef\\0\\somegroup\\someproj.git\\CA_SERVER_TLS_CA_FILE
[...]
quoted
C:\Users\jreinhart\testrepo>set GIT_CURL_VERBOSE=1
C:\Users\jreinhart\testrepo>git fetch
[...]
quoted
* CAfile: C:\Users\gitlab-runner\builds\deadbeef\0\somegroup\someproj.git\CA_SERVER_TLS_CA_FILE
[...]
quoted
C:\Users\jreinhart\testrepo>git checkout master
C:\Users\jreinhart\testrepo>git submodule update --init
[...]
quoted
* CAfile: C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
[...]
quoted
Note that the CAfile reverted to its default instead of using the same
one from the `git fetch`.
Interesting.
The context is that "git submodule update" is simply running commands
like "git fetch" inside the submodules, and the repository-local
config of the superproject does not apply there.
In the long run, commands like "git fetch --recurse-submodules" may
chaange to use a single process. It's possible that some of the
repository-local configuration of the superproject would apply at that
point, though the inconsistency would be confusing, so probably not
these particular settings. Anyway, that's a faraway future; today,
"git fetch --recurse-submodules" is also running "git fetch" commands
inside the submodules, and the repository-local config of the
superproject does not apply there.
Would it work for you to put this configuration in the global config
file ("git config --global --edit")? That way, it would be used by
all repositories. If you want it only to apply within the testrepo
directory, you can use conditional includes --- something like:
in $HOME/.git/config/testrepo-ca:
[http "https://gitlab.example.com"]
sslCAInfo = ...
in $HOME/.git/config/git:
[includeIf "gitdir/i:~/testrepo/**"]
path = testrepo-ca
Thanks and hope that helps,
Jonathan