Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vendor mode does not remap cross-repo symlinks to vendor dir #22303

Closed
peakschris opened this issue May 9, 2024 · 1 comment
Closed

Vendor mode does not remap cross-repo symlinks to vendor dir #22303

peakschris opened this issue May 9, 2024 · 1 comment
Assignees
Labels
P1 I'll work on this now. (Assignee required) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: bug

Comments

@peakschris
Copy link

Description of the bug:

When vendoring a repo such as rules_helm, which contains symlinks between its sub-repos, the symlinks are not remapped on vendoring. This means the resulting directories in the vendor_dir contains symlinks into the bazel user cache, and become dangling if the vendor_dir is copied to a different machine.

Which category does this issue belong to?

No response

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Module.bazel:
bazel_dep(name = "rules_helm", version = "0.3.2")

bazel vendor --vendor_dir=vendor
dir vendor\rules_helm~~helm~helm\helm.exe
<note resulting file is a symlink that points into user cache>

Which operating system are you running Bazel on?

windows, but I suspect this is a general problem

What is the output of bazel info release?

7.2.0 latest (8c6220a)

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

No response

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

There is also an issue in rules_helm on Windows with the rules_helm symlink, but this is unrelated to this reported issue: abrisco/rules_helm#78. I have validated this by fixing the rules_helm issue locally.

@sgowroji sgowroji added the team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. label May 9, 2024
@fmeum
Copy link
Collaborator

fmeum commented May 9, 2024

This is the relevant line in rules_helm:
https://github.com/abrisco/rules_helm/blob/main/helm/repositories.bzl#L130

@meteorcloudy meteorcloudy self-assigned this May 28, 2024
@meteorcloudy meteorcloudy added P2 We'll consider working on this in future. (Assignee optional) and removed untriaged labels May 28, 2024
@meteorcloudy meteorcloudy added P1 I'll work on this now. (Assignee required) and removed P2 We'll consider working on this in future. (Assignee optional) labels Jun 11, 2024
meteorcloudy added a commit to meteorcloudy/bazel that referenced this issue Jun 18, 2024
To make sure symlinks work correctly, Bazel uses the following strategy to rewrite symlinks in the vendored source:

  - Create a symlink `<vendor_dir>/bazel-external` that points to `$(bazel info output_base)/external`. It is refreshed by every Bazel command automatically.
  - For the vendored source, rewrite all symlinks that originally point to a path under `$(bazel info output_base)/external` to a relative path under `<vendor_dir>/bazel-external`.

Fixes bazelbuild#22303

Closes bazelbuild#22723.

PiperOrigin-RevId: 644349481
Change-Id: I853ac0ea5405f0cf58431e988d727e690cbbb013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P1 I'll work on this now. (Assignee required) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants