What can I do about the error: Invalid submodules in repository?

Questions & Answers
#1

On a deploy, you may get a failure with the message like:

E: Error parsing configuration files:
: Invalid submodules in repository.

E: Error: Invalid configuration files, aborting build

Maybe also :

Please contact support for more information,
specifying event ids

There are at least two common reasons for this.

Platform.sh supports git submodules, and will do its best to retrieve them, recursively, on any deployment.

Private (or inaccessible) submodule repositories

This should be straightforwards to identify.

As described in Using Git Submodules and Using a private Git repository, you probably need to supply a deploy key or check your authentication process.

Check the documented process for that, and review the access requirements. Raise a ticket quoting the reference number if you are still having issues.

But I’m not using submodules!

If you get this error, but don’t even have a .gitmodules in your project, what’s going on?

This can happen in cases where submodules were apparently once in use, but traces of old submodules haven’t been cleanly removed.

The issue lies within your app code (the git repository history to be precise) but it is only exposed when Platform.sh deployment attempts to update recursively for you.

This situation may persist invisibly for years, if you only ever do a git checkout , but it surfaces when a deployment (like platform.sh) uses the git submodule update --recursive option - or a command to that effect.

Even though you may not have a .gitmodules in your project today, there may be old repo pointers at the ghost submodules. This can be caused by a developer doing a git clone of a submodule directly inside your project, or maybe by copying a module folder that brings its own history along.

Identify the problem

This can be established on your own copy of the codebase with an attempt at running

git submodule status

There you should be able to replicate the Invalid submodules in repository message for yourself.

(staging) $ git submodule status
fatal: no submodule mapping found in .gitmodules for path 'web/profiles/openpublic/libraries/colorbox'

Remove the problem

I’ve found it usually good enough to

  • Check the named directory
  • And if it’s not really in use, (I’ve so far found these to be empty, probably made redundant by composer at some point) - git rm it.
  • Then try git submodule status again and repeat. There can be multiple instances of the same problem, but only one gets reported at a time.

This oddness may be found in other parts of your project history, as it’s invisible, and may have been there for a while.

1 Like