- From: James Graham <james@hoppipolla.co.uk>
- Date: Thu, 08 May 2014 23:19:59 +0100
- To: public-test-infra@w3.org
On 08/05/14 20:42, Travis Leithead wrote: > I asked some folks at Microsoft about this, and they all confirmed > that its true (one even remembers filing the bug years and years > ago--guess it's still not fixed?) One possible alternative is to use > the Unicode-versions of these functions (if that's an option) which > may not have this limit (MAX_PATH). I think the problem is that our build and test infrastructure uses components that can't handle the new-style paths,. Fixing that is too much ocean to boil, so we need a solution that works within the 260 character limit. It looks like for Mozilla infrastructure limiting paths in the test repo to either 160-170 characters would work. The higher limit wouldn't require any changes on the test side but would be quite tight to the limits (or indeed hit some limit I haven't found yet) and could conceivably break for people building on Windows with longer paths to their checkout. The former would require changing 2 existing tests. If we wanted to give ourselves even more breathing room, there are 6 tests with > 150 characters in the path, 82 > 140 and 238 > 130. I wonder if it would be worth going to 150 as a limit? Does anyone else know of path prefix length requirements from infrastructure on which they want to run the tests? In any case we need some kind of automatic enforcement here. Since we don't get pre-commit hooks on GitHub, I wonder if it's possible to use TravisCI to lint incoming test submissions. There are some other simple things that we could check for like trailing whitespace (with a whitelist of files that require it ofc).
Received on Thursday, 8 May 2014 22:20:23 UTC