What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
For a multi-repository project, keep each dependency at an explicit commit and make CI check out that exact commit, including any nested submodules. A Git submodule is not a copied folder: the superproject records a gitlink pointing to a commit in the submodule’s own repository. CI must also be configured to populate submodules and obtain credentials that can read every private dependency. With two CI systems, first decide which system owns each check and how both validate the same pinned set of commits.
What a gitlink records—and what it does not
A submodule is a separate Git repository checked out beneath a superproject. The superproject’s tree contains a gitlink entry naming the commit expected at the submodule path; it does not copy the dependency’s files or history into the superproject. The submodule retains its own repository history. Git’s submodule documentation describes the gitlink as the commit the superproject expects the submodule working directory to be at.
The .gitmodules file maps a submodule’s logical name to its working-tree path and default clone URL. A relative URL is resolved against the superproject’s origin. That can be convenient when related repositories move together, but GitLab warns it may resolve incorrectly in fork workflows; use an absolute URL if forks are expected. Git’s .gitmodules documentation explains the configuration, and GitLab Runner’s configuration documentation discusses the fork caveat.
How to change a dependency without losing reproducibility
By default, git submodule update checks out the commit recorded by the superproject. The submodule is commonly left on a detached HEAD, which is suitable for a build but not a place to make a commit you intend to maintain. Git’s submodule command documentation covers update behavior; the free online Pro Git submodules chapter walks through a practical workflow.
#1 Best Overall
-
In the submodule, switch to or create a working branch before editing.
-
Commit and publish the change to the submodule’s own repository.
-
Return to the superproject and stage the submodule path. Git records the new commit as a changed gitlink.
Recommended: Fix Windows Errors and Clear Junk Files in Minutes - Free Scan →Recommended: Update Every Outdated Driver on Your PC in One Scan - Free →Recommended: PC Feels Slow? A Free Scan Shows What's Dragging Windows Down →Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy. -
Commit and publish the superproject change so the dependency update is explicit and reviewable.
A build that follows a branch’s latest remote commit can change even when the superproject has not changed. GitLab documents the security, stability, and reproducibility risks of using --remote; its guidance says that, in most cases, projects should explicitly track submodule commits and update them deliberately, for example with a dependency bot. See GitLab Runner configuration.
Rank #2
- Used Book in Good Condition
What CI must do differently from a local checkout
A successful checkout of the superproject does not by itself guarantee that submodule working trees are populated. The CI checkout phase must initialize and update them at the recorded commits. If a submodule contains its own submodules, checkout must also recurse into those nested dependencies. Separately, the job needs credentials authorized to read each private repository; a checkout option cannot grant repository access that the token does not have.
-
Pin the dependency: use the gitlink recorded by the superproject rather than allowing the build to drift to a moving branch head.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy. -
Populate the required depth: initialize top-level submodules, or use recursive initialization for nested ones.
-
Authorize every private repository: confirm the credential’s scope and the target repository’s access policy.
-
Keep credentials job-safe: avoid persistent global Git credential changes on shared shell executors, where a later job could inherit them.
GitLab CI/CD: configure depth, recursion, and access
GitLab Runner uses GIT_SUBMODULE_STRATEGY to control checkout: normal initializes top-level submodules, while recursive also handles nested submodules. The runner documentation also describes GIT_SUBMODULE_DEPTH, GIT_SUBMODULE_PATHS, and GIT_SUBMODULE_UPDATE_FLAGS; for example, update flags can pass --jobs to fetch in parallel. Submodule depth is separate from the main repository’s GIT_DEPTH. Consult the current GitLab Runner configuration documentation for syntax and version-specific behavior.
Free tools Windows power users keep installed
One-click scans. No signup required.
For a private submodule fetched with CI_JOB_TOKEN, the submodule project must allow job-token access, and the user whose permissions apply to the job must have an appropriate role. A GitLab job token from one GitLab instance cannot authenticate to a different instance; for that case, use a credential for the external instance that has repository read access, and store it as a protected, masked CI variable. Follow current Runner guidance for credentials used by later Git commands inside submodule directories: externalized credentials may not automatically carry over. Verify behavior in the actual runner environment, especially when using a shell executor. The relevant details are in GitLab Runner’s configuration documentation.
GitHub Actions: checkout option and token scope
The official actions/checkout documentation supports submodule checkout with submodules: true or submodules: recursive. The recursive setting is the appropriate choice when nested submodules must be populated. The documentation also states that github.token is scoped to the current repository. A private or internal secondary repository therefore needs the documented separate credential option and a token with suitable access. Check the exact action version, workflow token permissions, and repository policy in use; enabling submodule checkout does not itself authorize access to another private repository.
How to divide work between two CI systems
“Dual CI” does not specify whether both systems build every repository, one validates while another deploys, or each repository owns its own pipeline. There is no single configuration implied by having two systems. Write down the project’s operating model before configuring triggers or credentials:
-
Repository ownership: which repository owns each component and its release process?
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchSpecial offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.Rank #4
-
Dependency direction: which repositories consume which other repositories, and are dependencies top-level or nested?
-
CI authority: which system is authoritative for each test, build, or deployment check?
-
Cross-repository triggers: what event should run checks elsewhere when a dependency changes?
-
Promotion unit: how will a tested combination of gitlink commits be reviewed and promoted together?
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsSpecial offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
For reproducible integration, treat the superproject commit as the record of a tested dependency combination. Each CI system that validates that combination should check out the same superproject revision and populate its submodules from the recorded gitlinks. If one pipeline validates a new dependency commit, update the gitlink in the superproject before treating that combination as the project’s tested state.
Best Value
Common failure points to check
-
Submodule directory is empty: confirm that the CI checkout initializes submodules and that the strategy is not limited to the main repository.
-
Nested dependency is missing: enable recursive handling and check the specific provider action or runner version’s behavior.
-
Private clone fails: verify the credential can read the dependency repository and that the project’s access policy allows it. Checkout configuration and authorization are separate.
Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy. -
Fork resolves the wrong repository: inspect relative submodule URLs; use absolute URLs if the fork layout makes origin-relative resolution unsuitable.
-
Build changes without a superproject commit: check for remote-tracking behavior such as
--remote; pin and commit the intended gitlink instead. -
Later Git command cannot authenticate: check how the runner makes credentials available inside submodule directories, and avoid persistent shared-shell configuration that can leak across jobs.
Quick Recap
SaleBestseller No. 1SaleBestseller No. 2SaleBestseller No. 3Bestseller No. 4
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
