## Problem After MR !5912 ("Externalize git configuration"), job tokens are no longer automatically injected when users manually manage submodules with `GIT_SUBMODULE_STRATEGY: none`. Previously, the `insteadOf` rules were available globally in the git config, making them accessible to any git operation. Now they're externalized to a separate config file that must be explicitly included. ### Impact Users who: - Set `GIT_SUBMODULE_STRATEGY: none` (disabling automatic submodule management) - Manually clone/fetch submodules in their build scripts - Rely on automatic job token injection via `insteadOf` rules ...will now encounter authentication failures when trying to clone private submodules, because the externalized git config is not automatically included in their manual git operations. ### Example Scenario **Before MR !5912:** ```bash # Job token automatically injected via insteadOf rules in main git config git clone https://git.mydomain.com/private/submodule.git # ✅ Works - credentials injected automatically ``` **After MR !5912:** ```bash # Job token NOT injected - externalized config not included git clone https://git.mydomain.com/private/submodule.git # ❌ Fails - terminal prompts disabled, no credentials ``` **Current Workaround:** ```bash # Users must manually include the externalized config git -c "include.path=$(git -C $CI_PROJECT_DIR config include.path)" clone https://git.mydomain.com/private/submodule.git # ✅ Works - but requires manual workaround ``` ## Root Cause MR !5912 moved the `insteadOf` rules from the main git config (which is inherited by all git operations) to an externalized config file (`.gitlab-runner.ext.conf`) that is: - Included in the template config for the main repository - Explicitly included via `-c include.path=...` for submodule operations that need credentials However, when `GIT_SUBMODULE_STRATEGY: none`, the runner doesn't set up these explicit includes, leaving manual git operations without access to the credential injection rules. ## Possible Solutions ### Solution 1: Export the externalized config path as an environment variable (Recommended) **Pros:** - Minimal breaking change - Users can opt-in to using it in their scripts - Backward compatible - Clear and explicit **Implementation:** - The runner already sets `GLR_EXT_GIT_CONFIG_PATH` internally (see `envVarExternalGitConfigFile` in `shells/abstract.go`) - Export this as a CI/CD variable so users can reference it: ```bash git -c "include.path=$GLR_EXT_GIT_CONFIG_PATH" clone https://git.mydomain.com/private/submodule.git ``` - Document this in the runner documentation **Code changes needed:** - In `shells/abstract.go`, export `GLR_EXT_GIT_CONFIG_PATH` as a CI/CD variable (similar to how `GITLAB_ENV` is exported) - Update documentation to explain the variable and its usage ### Solution 2: Add the externalized config to the global git config **Pros:** - Fully backward compatible - No user action required - Works for all git operations automatically **Cons:** - Credentials are now in the global git config (though still externalized) - May have unintended side effects on other git operations - Slightly less secure than keeping credentials isolated **Implementation:** - In `setupTemplateDir()`, also add the externalized config include to the global git config (not just the template) - This would make the `insteadOf` rules available to all git operations ### Solution 3: Provide a helper script/function **Pros:** - Flexible and reusable - Can be documented clearly **Cons:** - Requires users to source/use the helper - More complex for users **Implementation:** - Provide a shell function in the build script that wraps git commands with the proper config includes - Document it as a best practice for manual submodule operations ### Solution 4: Automatically include externalized config for all git operations (when GIT_SUBMODULE_STRATEGY=none) **Pros:** - Fully backward compatible - No user action required **Cons:** - Changes behavior for all git operations - May have unintended side effects **Implementation:** - When `GIT_SUBMODULE_STRATEGY: none`, set a git config option or environment variable that automatically includes the externalized config for all git operations - This could be done via `GIT_CONFIG_GLOBAL` or similar mechanism ## Recommendation **Solution 1** is recommended because it: 1. Maintains backward compatibility 2. Gives users explicit control 3. Requires minimal code changes 4. Is well-documented and discoverable 5. Aligns with the design of MR !5912 (explicit credential management) The environment variable `GLR_EXT_GIT_CONFIG_PATH` is already being set internally; it just needs to be exported as a CI/CD variable so users can access it. ## Related Issues - MR !5912 - "Externalize git configuration" (introduced this regression) - Issue #39169 - Custom clone_url breaks submodule authentication (related credential injection issue) ## Testing Test with: - `GIT_SUBMODULE_STRATEGY: none` - Manual git clone/fetch operations in build scripts - Private repositories requiring authentication - Verify that either: - The environment variable is available and works as documented, OR - The chosen solution provides automatic credential injection