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.
This should be straightforwards to identify.
Check the documented process for that, and review the access requirements. Raise a ticket quoting the reference number if you are still having issues.
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.
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'
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) -
- Then try
git submodule statusagain 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.