Using kitchen_root as part of the instance name produces clashes or too long names #210
Comments
|
I'd like to +1 this as I've been battling a problem with the Hyper-V provider and path name exceeding the 260 character limit in Windows caused by the concatenation of cookbook, suite and platform. I'd also like to suggest that |
|
I closed the existing PR but will open a new one myself |
|
+1 here. We started running into numerous windows agent build failures after pushing an upgrade to chefdk 2.1.11 |
|
+1 encountered major issues launching vagrant from windows test-kitchen after chefdk 2.1 Also think it might have to do with this commit not allowing spaces in path name on line 429: |
|
can you use or can test-kitchen be modified to use extended length paths with the "\?" prefix? |
|
I might be misunderstanding the question but the limit is really at the windows OS level. 260 characters is the max before the OS shuts you down. |
|
an example of a path generated too long for windows: |
|
a substring or a digest on 1503316491808_83138 might be feasible. It looks like default made it into the path twice. |
|
Could we omit One consequence: machines listed in the hypervisor would not have |
This omits "kitchen-#{something}" from the vagrant root directories that
will appear under .kitchen/kitchen-vagrant.
Windows users will run into a path length limit of 260 characters.[1]
We have been repeating in the directory structure "kitchen-" and the
basename of kitchen-root--the directory that contains the .kitchen.yml
which most of the time works out to be the name of the cookbook being
tested. This made for meaningful if verbose names for virtual machines
so as to correlate a machine running in a Vagrant-supported hypervisor
to a test-kitchen config.
The inclusion of this string was _not_ for any unique identifier to
avoid naming collusions within the hypervisor. This change should be
safe for an upgrade for kitchens that have running instances prior to
upgrade. The state file for a machine that was successfully created will
have recorded the vagrant_root path used at creation time. This will
allow kitchen commands to continue to operate on the running instances.
[1] #210
Signed-off-by: Robb Kidd <[email protected]>
|
Proposed fix (omit |
This omits "kitchen-#{something}" from the vagrant root directories that
will appear under .kitchen/kitchen-vagrant.
Windows users will run into a path length limit of 260 characters.[1]
We have been repeating in the directory structure "kitchen-" and the
basename of kitchen-root--the directory that contains the .kitchen.yml
which most of the time works out to be the name of the cookbook being
tested. This made for meaningful if verbose names for virtual machines
so as to correlate a machine running in a Vagrant-supported hypervisor
to a test-kitchen config.
The inclusion of this string was _not_ for any unique identifier to
avoid naming collusions within the hypervisor. This change should be
safe for an upgrade for kitchens that have running instances prior to
upgrade. The state file for a machine that was successfully created will
have recorded the vagrant_root path used at creation time. This will
allow kitchen commands to continue to operate on the running instances.
[1] #210
Signed-off-by: Robb Kidd <[email protected]>
Hi,
I have issue with using {kitchen_root_directory} as part of the instance name due to directories with the same name or producing instance names that are too long.
How about using a CRC32 of the full path?
It would make the instance name unique and shorter, getting the actual path would still be easy by running vagrant global-status and it should be quite easy to implement too.
Any thoughts?
The text was updated successfully, but these errors were encountered: