Getting actions workflow failed at checkout stage with error

[ishuallawadhi]

: fatal: No url found for submodule path 'xyz' in .gitmodules Error: The process '/usr/bin/git' failed with exit code 128

[tchelovilar]

Did you managed to solve? I tried execute: git rm --cached <module_path>

But I got the error again.

[ghost]

I have the same issue. Any ideas/

[tchelovilar]

@huihuiy02 Yes, I managed to fix removing the submodule: git rm --cached <path_to_submodule>

And push the changes

But the error still happening in the self runner then I needed to remove the workflow folder from _work dir in the github runner home dir.

[ghost]

Thanks, that works for me.

[cosimo]

But the error still happening in the self runner then I needed to remove the workflow folder from _work dir in the github runner home dir.

This seems to be related to the error for us. We are using self-hosted runners. Wiping the entire _work directory "cures" the issue, though I'm not sure what the problem is. I will be looking into this.

UPDATE: this seems to be related to the fact that we are using this workaround to use a private actions repository for our org. The checkout happening in .github/private-actions is what is causing this issue, at least that's my current theory.

See also: https://github.com/actions/checkout/issues/385

[cosimo]

Would this be a suitable patch for src/git-auth-helper.js? It seems it would possibly solve the problem, hopefully not creating new ones.

diff --git a/src/git-auth-helper.ts b/src/git-auth-helper.ts
index 291d83b..6783f47 100644
--- a/src/git-auth-helper.ts
+++ b/src/git-auth-helper.ts
@@ -329,22 +329,24 @@ class GitAuthHelper {
 
   private async removeGitConfig(
     configKey: string,
     submoduleOnly: boolean = false
   ): Promise<void> {
     if (!submoduleOnly) {
       if (
         (await this.git.configExists(configKey)) &&
         !(await this.git.tryConfigUnset(configKey))
       ) {
         // Load the config contents
         core.warning(`Failed to remove '${configKey}' from the git config`)
       }
     }
 
-    const pattern = regexpHelper.escape(configKey)
-    await this.git.submoduleForeach(
-      `git config --local --name-only --get-regexp '${pattern}' && git config --local --unset-all '${configKey}' || :`,
-      true
-    )
+    if (this.settings.submodules) {
+      const pattern = regexpHelper.escape(configKey)
+      await this.git.submoduleForeach(
+        `git config --local --name-only --get-regexp '${pattern}' && git config --local --unset-all '${configKey}' || :`,
+        true
+      )
+    }
   }
 }

Tests are failing with this change. I'm currently looking into what this means.

[ace03uec]

https://github.com/actions/checkout/issues/354#issuecomment-759282642 This solution worked for our specific usecase, @cosimo could you point out which tests failed ? Perhaps we can check the same.

[cosimo]

#354 (comment) This solution worked for our specific usecase, @cosimo could you point out which tests failed ? Perhaps we can check the same.

Sorry, I did abandon this solution and proposed patch since I discovered it's possible to side-step the whole issue by adding the private actions repository checkout directory to your .gitignore file and that solved all our issues permanently, also when using self-hosted runners.

[caioaamaral]

I had the same problem today after adding a broken git submodule by mistake on a PR. My temporary solution was to apply a fresh start on my docker's self-runners.

Would be great having a fix for this one.

[ckcks12]

It happened to me and had taken my hours away.

As far as I dug, it happened because of one "dirty" submodule on the other branch. "dirty" means the path was registered as a submodule somewhere somehow but I couldn't find where it is being managed. My git itself was clean. I proved it by cloning the repo and setting it up several times. The problem was the Github runner, the checkout actions. I couldn't find what exactly the cause is. Somehow the checkout actions kept stale and dirty submodule information in its .git I guess.

However, its side effect was huge. The problem branch broke the whole branches' workflow. It was a nightmare. All I could do was just reboot self-hosted runners.

Hope it would be fixed anytime soon.

[rr-anil-gupta]

Rebooting the runner did help. Thank @ckcks12

[smerdov]

Deleting .git directory solved the problem. Of course, it's better to backup it beforehand (so I just renamed it like mv .git .oldgit)

[gannaramu]

upvoting this, the issue still exists.

[andychongyz]

Adding the step below before checkout works for me.

- name: Clear repository
        run: sudo rm -fr $GITHUB_WORKSPACE && mkdir $GITHUB_WORKSPACE

[michael1997]

Same issue. Fixed with a restart of our self-hosted runners

[lackhole]

Any updates?

[nlundegard1-chwy]

any update on this?

[jokreliable]

We've experienced this as well. And I just spent some time trying to wrap my head around the problem.

Best I can tell, the flow, when it breaks, goes like this:

• Starting here where we process the "Setting up auth" group...
• the chain of call from there goes like this: configureAuth() -> removeAuth() -> removeSsh() -> removeGitConfig(SSH_COMMAND_KEY)
• Ultimately, we end up here where we try to run a cleanup of the config key on each submodules, if any and fails when one of the submodules is new.

The submoduleForeach() call then runs the command. The command generated, in the end looks like this:

/usr/bin/git submodule foreach --recursive git config --local --name-only --get-regexp 'core\.sshCommand' && git config --local --unset-all 'core.sshCommand' || :

I believe the intended effect is in pseudo code:

foreach submodules {
  get the name of the option `core.sshCommand`
  if the option is found, unset it in the submodule
  else just continue anyway.
}

However, what is actually happening is

foreach submodule {
  get the name of the option `core.sshComnand`
}
if the scan above worked for *every* submodule, remove it from the main repo and if the removal fails, continue anyway.

I expect the fix would be something like updating the code here to wrap command in quotes, to have the proper behavior.

[neilenns]

I'm also now hitting this issue. My github action checks out the main repo, and then checks out another repo nested (following the exact yaml in the checkout action documentation for this scenario).

After the workflow completes the last step attempts to do the post checkout job cleanup for the main repo and fails:

Post job cleanup.
/usr/bin/git version
git version [2](https://github.com/neilenns/Collins-FMS-3000/actions/runs/3395142310/jobs/5644633491#step:28:2).[3](https://github.com/neilenns/Collins-FMS-3000/actions/runs/3395142310/jobs/5644633491#step:28:3)8.1
Temporarily overriding HOME='/home/runner/work/_temp/fa051259-9ca9-[4](https://github.com/neilenns/Collins-FMS-3000/actions/runs/3395142310/jobs/5644633491#step:28:4)c0c-bb39-423481f3fb9c' before making global git config changes
Adding repository directory to the temporary git global config as a safe directory
/usr/bin/git config --global --add safe.directory /home/runner/work/Collins-FMS-3000/Collins-FMS-3000
/usr/bin/git config --local --name-only --get-regexp core\.sshCommand
/usr/bin/git submodule foreach --recursive git config --local --name-only --get-regexp 'core\.sshCommand' && git config --local --unset-all 'core.sshCommand' || :
fatal: No url found for submodule path 'KiCad[6](https://github.com/neilenns/Collins-FMS-3000/actions/runs/3395142310/jobs/5644633491#step:28:6)-Components' in .gitmodules
Warning: The process '/usr/bin/git' failed with exit code 12[8](https://github.com/neilenns/Collins-FMS-3000/actions/runs/3395142310/jobs/5644633491#step:28:8)

KiCad6-Components is the nested cloned repo

[hyrefeldt-ourstudio]

This still seems to be a problem.

Now I ran into this issue as well, even though the submodule that the error talks about was deleted many months ago. As it has been mentioned here in this issue it seems to happen only for the self-hosted runners.

Run actions/checkout@v2
Syncing repository: xxx/xxx
Getting Git version info
Temporarily overriding HOME='/runner/_work/_temp/1fa48f0d-f211-40d7-88c7-261adc94292e' before making global git config changes
Adding repository directory to the temporary git global config as a safe directory
/usr/bin/git config --global --add safe.directory /runner/_work/cce-rule-set-resolver/cce-rule-set-resolver
/usr/bin/git config --local --get remote.origin.url
https://github.com/xxx/xxx
Removing previously created refs, to avoid conflicts
Cleaning the repository
Disabling automatic garbage collection
Setting up auth
  /usr/bin/git config --local --name-only --get-regexp core\.sshCommand
  /usr/bin/git submodule foreach --recursive git config --local --name-only --get-regexp 'core\.sshCommand' && git config --local --unset-all 'core.sshCommand' || :
  Error: fatal: No url found for submodule path 'the-old-removed-submodule' in .gitmodules
  Error: The process '/usr/bin/git' failed with exit code 128

If I remember correctly i removed the submodule with

git rm <path-to-submodule>

as this Stack Overflow post describes.

UPDATE: Restart of runners seemed to solve the problem.

[seemethere]

Can we stream line this into the v2 tag? I'm hitting this with a lot of our workloads recently and the problem only seems to be getting worse

[cory-miller]

v2 and v3 tags are updated to point to a release containing https://github.com/actions/checkout/pull/964. Please re-open if this did not address the problem.

[Benbentwo]

Still an issue, not fixed by restarting for me. This shouldn't even be happening with

    # Default: false
    submodules: ''

correct?

[louwers]

Still a problem with self-hosted runners.

I created a new issue: #1358

@cory-miller You might want to re-open this and close the other issue.

[DeboBurro]

Still having this issue on self-hosted runners. Restart the runner service doesn't help.

[update] I found out why in our case. In our self-hosted runner machine,

1. We pushed a tag to build an old branch that has a packages/submodule_folder_path and a .gitmodules pointing to that submodule folder path. ( this makes the submodule folder persist after that build finishes )
2. Later we pushed a tag to build a new branch that still have packages/submodule_folder_path (we forgot to remove that) but the .gitmodules doesn't have an entry pointing to that submodule folder path. so the checkout actions is complaining about

Error: fatal: No url found for submodule path 'packages/$submodule_folder_path' in .gitmodules

So we fixed that by:

1. in the new branch, we git rm packages/$submodule_folder_path
2. git commit -m 'remove the submodule' && git push
3. git tag v0.0.0-abc
4. SSH into the self-hosted runner server and rm -rf the git clone folder
5. git push v0.0.0-abc to trigger the build
6. And it's fixed.

Weird thing is that, if the submodule entry does not exist in the .gitmodules, why would the checkout action still try to pull the submodule?

[prein]

On self-hosted runner the workdir may contain the files from a checkout step from a run that was scheduled on the same runner pod previously. Some of the issues mentioned in this thread are caused by that. What might work for you: add a step before checkout to rm -rf previous checkout and/or use an own action wrapping on actions/checkout to include pre and post steps that do the rm

[vladimir-voinea]

Running this in PowerShell as Administrator will fix it:

git config --system core.usebuiltinfsmonitor false

[kaidokert]

Just mentioning again that i have an open PR waiting to resolve the tail end of those issues: https://github.com/actions/checkout/pull/1321 ( opened #1321 )