Integration tests broken on windows due to Maximum Path Length Limitation

[se7entyse7en]

Caused by #189.

In Windows, there's a Maximum Path Length Limitation (source), and during integration tests, this limit is reached.

This is the path of the docker-compose.yml file:

C:\Users\Windows10\AppData\Local\Temp\TestInitLocalTestSuite_TestChangeWorkdir131516411\sourced\workdirs\local\QzpcVXNlcnNcV2luZG93czEwXEFwcERhdGFcTG9jYWxcVGVtcFxUZXN0SW5pdExvY2FsVGVzdFN1aXRlX1Rlc3RDaGFuZ2VXb3JrZGlyMTMxNTE2NDExXHdvcmtkaXJfYQ==\docker-compose.yml

whose length is 262. I tried to rename the test name to the shorter TestChWD and all the tests pass. The effect of this limitation can also be seen by cd-ing in the directory and try to run docker-compose from there. Even in this case docker-compose fails to see the docker-compose.yml file. Even simply catting the file fails.

For normal uses, this shouldn't be very likely to happen, but still, it could. We could add a limit to the generated b64 string, and this would require changing the way we retrieve the human-friendly name of the workdir. With the current .env file we already have the followings:

• GITBASE_VOLUME_SOURCE key for local initialization,
• GITHUB_ORGANIZATIONS key for orgs initialization.

Maybe we could add a more explicit key such as WORKDIR_SUBJECT or WORKDIR_WHATEVER.

[carlosms]

Adding a limit to the base64 string will break decoding, and may cause collisions for paths and sub-paths.

As discussed in today's team focus meeting, we can leave this problem as a known issue and try to fix it later. Maybe using the \\?\ prefix as said on the documentation liked above, or maybe just enabling long paths in the registry in our dev machine to be able to run the tests.

[smacker]

We can also run tests with TMPDIR_INTEGRATION_TEST=C:\tmp to make tests work.