Submodule and Symoblic Links combo

Hi, we're trying to use cloud build with git submodules in a specific way

We have seperate submodule unity projects outside of the main unity project but in the same repository, we then symlink the relevant folders into the main project.

When the cloud build tries to build it, it doesn't seem to like the symbolic links from the submodule, here is a snippet of log:

The errors make me suspect the symbolic links aren't working.

I have placed the appropriate cloud build SSH key in the deployment keys of all the repositories and all the urls are using git@ not https:// or git://

So now I'm a bit stumped of what it could be, I suppose my first question is, which I couldn't find a solid answer to, does UCB support symbolic links?

Ta!

 

Has anyone managed to get symbolic links working in UCB?

 

We use git submodules outside of the unity project, but still in the repository, and then on windows use the cmd mklink to create links into the unity project from those submodules. This means we can split up code into modules that can be tested as unity projects individually, while also quickly and closely integrating with other projects.

The symbolic links are recognised by git, though sometimes we have to run

Code (CSharp):

1. git config core.symlinks true

to get it to recognise them, though that might have something to do with the git client we use, I think git should make it true by default if it has symlinks in the repository.

I hope you can make a good unit test with that information!

 

Ok, so it was a mistake on my end (isn't it always!) I had the relative path of a symbolic link wrongly submitted to Git, it works now, so for those wondering, Git Submodules + Symlinks with Unity Cloud Build works! Exciting stuff!

 

I know this is an old thread but, how does git works with your symlinks? When I create a symlink on windows with mklink /d the symlink is created, but when cloned on antoher computer, or I change branches, the symlink breaks

 

@Huszky and whoever else might be wondering about this. I suspect that the symlinks in your repo are to folders and when cloning, git creates file type symlinks instead. As discussed here and here, this is because the symlink type information is not stored on git and so git has to determine the type from the target, which fails if the target doesn't exist yet, as may be the case for a submodule. It seems git then defaults to type file. A solution/work-around proposed on the second page referenced above is to add a .gitattribute file and set the type of the symlinks to folder explicitly like so symlink=dir. I actually tried that only yesterday and it worked for us so far.

Any confirmation on this from someone else would be much appreciated!

 

Thank you for sharing this found. I do confirm it works perfectly fine when you do not have spaces in your paths.
With spaces, though, it didn't work for me even when replacing them with [[:space:]] tag according to the .gitattributes syntax. Not sure if it's a git bug, or I just misconfigured something.

Here is an example of working .gitattributes file I'm using for my Advanced FPS Counter repo: