Skip to content
This repository has been archived by the owner on Oct 2, 2023. It is now read-only.

container_test broken when using container-structure-test 1.6 #600

Closed
Monnoroch opened this issue Dec 4, 2018 · 9 comments
Closed

container_test broken when using container-structure-test 1.6 #600

Monnoroch opened this issue Dec 4, 2018 · 9 comments
Labels
Can Close? Will close in 30 days unless there is a comment indicating why not

Comments

@Monnoroch
Copy link

Monnoroch commented Dec 4, 2018

I tried to override the container-structure-test dependency from 1.4 to 1.6 and got this error:

Error: error creating driver: processing tar image reference: mkdir /tmp/root.cachebazel_bazel_rootdce6ed4f9b6b93214722cd6fa27af714execrootastrabazel-outk8-fastbuildbinsomeveryveryveryveryveryveryveryveryveryveryverylongname_test.runfilessomeveryveryveryveryveryveryveryveryveryveryverylongname.tar@sha256:27157e6b7e4373f939de9c51191487f9cbf80e6e7f132445fa5a2d605c3e39fb691144971: file name too long

1.5 is working though. I realize that strictly speaking 1.6 is "not supported" but the upgrade will happen at some point and this issue will have to be fixed.

See related discussion in GoogleContainerTools/container-structure-test#183.

@nlopezgi
Copy link
Contributor

nlopezgi commented Dec 4, 2018

could you post instructions to repo the error (seems a very long file name is needed?). Also, is this something can be fixed here or is the issue that container test v1.6 is broken and they should fix?

@Monnoroch
Copy link
Author

Monnoroch commented Dec 4, 2018

A very long file name is not needed. I just update the container-structure-test dependency to 1.6 and call bazel test //... on my repo. I'll try to come up with a minimal example tomorrow, but it's Bazel (or, rather Bazel and the rules) who generates file names. My guess is that in the new version they just use slightly longer names and right now the names are already very close to the limit. Please take a look at the related issue in container-structure-test repo.

@nlopezgi
Copy link
Contributor

nlopezgi commented Dec 4, 2018

thoughts about whether there is any fix here or it's a broken release?

@Monnoroch
Copy link
Author

The release is fine, it works perfectly as a standalone software. It's bazel test //... who generates long names.

@nlopezgi
Copy link
Contributor

nlopezgi commented Dec 5, 2018

i'm sorry to push on my line of question, but you only answered half my question. Do you think there anything we can do in this repo to fix?

@Monnoroch
Copy link
Author

Here is a more detailed file name generated:

/tmp/homemonnoroch.cachebazel_bazel_monnoroch0a678f6ad8dbaaba9053e7774197befbsandboxlinux-sandbox3execroot${workspace_name}bazel-outk8-fastbuildbin${package_path}${container_test_target_name}.runfiles${workspace_name}${package_path}${container_image_target_name}.tar@sha256:3c0db08cdeed96c0d85bd3b6b10dab11f8281fdff96ef9fda7f93d20aa89afa3308596592: file name too long

My ${package_path} is 32 characters long, my workspace name is 5 characters long, my target names are at most 10 characters long. There's nothing unreasonable here, though I notice that the package name is used twice and that there's the image digest which is super long by itself.

Overall I would just say that the probability of getting a long file name is super high right now. short_path here is not short at all.

This is all I know so far, I'm not a huge expert on hacking Bazel just yet, but the container_test rule seems super simple and it looks like it's the long short_path is at fault here.

@nlopezgi
Copy link
Contributor

nlopezgi commented Dec 5, 2018

Sorry but that does not answer my question. contaniner_test is not part of this repo, and Bazel defines how file names are created (https://github.com/bazelbuild/bazel). So I honestly do not see any action that can be taken on this repo to fix this issue. I want to point this out as posting this issue here will likely not get you to a resolution.

@github-actions
Copy link

This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days.
Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_docker!

@github-actions github-actions bot added the Can Close? Will close in 30 days unless there is a comment indicating why not label Mar 18, 2021
@github-actions
Copy link

This issue was automatically closed because it went 30 days without a reply since it was labeled "Can Close?"

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Can Close? Will close in 30 days unless there is a comment indicating why not
Projects
None yet
Development

No branches or pull requests

2 participants