Git submodules cannot be checked-out / updated with CI token

The script produced makes no provisions for checking-out or updating git submodules. This is difficult for reasons outlined in gitlab-org/gitlab-ci#224 gitlab-org/gitlab-ce#18107.

Added improvement label

Ran into this issue, worked around it by:

• hosting the submodule on github
• adding commands to do a proper git submodule update --init --recursive
• don't forget to git submodule sync before everything else, to update changes in .gitmodules in case you're in fetch-mode.

@BenWiederhake I hardly think "hosting the submodule on github" is a relevant workaround. You could achieve the same by making the project "public" on your GitLab instance.

I think using deployment keys with ssh injection via ssh-agent solves this. It's rather simple: http://docs.gitlab.com/ce/ci/ssh_keys/README.html

@dar If you follow the link to gitlab-org/gitlab-ci#224 you'll see that I understand that deploy keys can be used for this purpose. However, I feel that it is a workaround which is difficult to maintain in complex module relationships, and doesn't "just work", the way the CI token does for the top-level project.

Definitely, some edges could be cleaned up, but you will ever need to specially authorize a "foreign" repo. I see no way the system can guess, which repos to have access to and to which not, of course your repo knows that it should have access to submodule repos, but the other repo doesn't. You would have to manage this access ever manually in some sort. Clearly a contextual help text could guide you, but that's all as to out of the box here.

The murky part, I see about deploy keys, is the injection. But I guess brainwork has been initiated on how to improve this workflow further.

See also gitlab-org/gitlab-ci-multi-runner#1569, which requests a simple change to make submodules just work.

Projects with submodules should be able to be checked out in a simple and easy way, as part of the Git clone/fetch/checkout process that is automatic -- the author of the .gitlab-ci.yml script shouldn't have to write git submodule update --init, and even worse shouldn't have to manage SSH keys etc.

Took me a couple of days to find this, so I'll push it everyware :)

Seems there is finally a reasonable solution:

http://docs.gitlab.com/ce/user/project/new_ci_build_permissions_model.html#sts=Git submodules %C2%B6

in short from gitlab 8.12 all you need to do is use relative paths in the .submodules, and the git submodule update --init will simply work

@ayufan Should this be closed now, since gitlab-org/gitlab-ce#18107 is resolved? I haven't personally tried it yet, so I can't confirm.

Also, I agree that manually putting git submodule update --init (--recursive?) in your before_script shouldn't be necessary. Perhaps the runner could do this ~automatically, controlled by an option like GIT_STRATEGY?

For me it mostly works ... when a different branch was being built. Then it failed untill i deleted the whole build folder.

The error i got was:

git submodule update --init --recursive

fatal: Authentication failed

Unable to fetch in submodule path 'utils'

ERROR: Build failed: exit status 1

@jonathon-reinhart

I agree that we should probably do git submodule update automatically. Maybe we should add a GIT_SUBMODULE_STRATEGY for controlling that?

@ayufan That would probably work. The next version could start doing git submodule update --recursive --initby default. If GIT_SUBMODULE_STRATEGY is nonrecursive then it could leave off the --recursive, and if it is none, then it could be left out altogether. I might be able to put an MR together next week.

I just discovered another reason why it is important that the runner perform the submodule clone (instead of requiring users add it to their before_script): In the case of a self-signed CA certificate, the super-project will be cloned by the runner, and somehow (@ayufan can you elaborate?) the CA certificate is injected into the gitlab-runner-prebuilt Docker container. But the sub-projects will fail because the user Docker image does not have that CA certificate:

$ git submodule update --init
Submodule ''example-subproject' (https://gitlab-ci-token:xxxxxxxxxxxxxxxx@gitlab.example.com/foo/example-subproject.git) registered for path 'example-subproject'
Cloning into 'example-subproject'...
fatal: unable to access 'https://gitlab-ci-token:xxxxxxxxxxxxxxxx@gitlab.example.com/foo/example-subproject.git/': server certificate verification failed.

@jonathon-reinhart

Yes, this is correct. It is available in clone phase.

Mentioned in issue #1569

Seems there is a new doc page for submodule: https://docs.gitlab.com/ce/ci/git_submodules.html

@ayufan I'm looking into implementing this.

I see in shells/abstract.go, that in both writeCloneCmd() and in writeFetchCmd(), the Git config option fetch.recurseSubmodules is explicitly set to false. From the documentation, this only option is only concerned with the actual fetching of submodules, and not the update or init-ing of them.

Does this have any bearing on this task?

mentioned in merge request !443 (merged)

closed via merge request !443 (merged)

mentioned in commit pjmorr/gitlab-ci-multi-runner@c8a5244b