The one place for your designs
Upload and view the latest designs for this issue. Consistent and easy to find, so everyone is up to date.
Apologies if this is the wrong place for this issue but it was experienced during the overall installation process and it affects one or more submodules (engine, front, sockets).
There is a .gitattributes file in the main Minds repo but it does not trickle down to the submodules. This means that if a user has line endings converted on checkout the installation shell scripts will fail. Additionally, this would protect against improper line endings being committed directly to a submodule. Obviously this isn't a major issue as it primarily affects Windows developers that have the convert line endings git option enabled as default.
Windows 10
Submodules are checked out and converted according to the user's global git preferences. Installation shell scripts fail.
Files are forced to be checked out with unix-style line endings like the main repo
(Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's very hard to read otherwise.)
Copy .gitattributes from main repo to each submodule repository, modifying as necessary for those projects
We want to be sure it is you, please confirm you are not a robot.
changed title from Git Attributes file does not apply to submodules, causes installation issues to Git Attributes file does not apply to submodules, potentially causes installation issues
added Triage::Review Type::Bug (Triage) scoped labels
marked this issue as related to #821
A bit more info on this bug:
This happens during docker-compose up installer
when it tries to run engine/containers/installer/install.sh
which has been checked out with windows-style line endings.
Let me know if you need any more info but I think a nice solution here would be to add the existing .gitattributes from the main repo into the engine repo.
See Is it possible that my .gitattributes file affects submodule?
Upon further inspection of the main repo .gitattributes
it's lacking a file type definition for *.sh
so this would need to be added to a gitattributes in the engine
repo in order to fix this.
Overall, I think it's a good practice to add .gitattributes
to each of the submodule repos.
@benhayward.ben I just now noticed you marked this as a similar issue to #821. From my understanding these issues are unrelated aside from both being installation issues involving submodules.
added Priority::2 - Normal Product::Platform Type::Bug scoped labels and removed Triage::Review Type::Bug (Triage) labels
Correct, my apologies they aren't hugely related actually. I see what you mean.
I'm not overly familiar with Windows. So when git checks out a branch on Windows, by default it converts files to CRLF - which is the windows default, if I recall correctly. Then in turn the scripts fail?
removed the relation with #821
Upload and view the latest designs for this issue. Consistent and easy to find, so everyone is up to date.