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

Bzlmod: vendor mode #19563

Open
SalmaSamy opened this issue Sep 19, 2023 · 5 comments
Open

Bzlmod: vendor mode #19563

SalmaSamy opened this issue Sep 19, 2023 · 5 comments
Assignees
Labels
area-Bzlmod Bzlmod-specific PRs, issues, and feature requests P1 I'll work on this now. (Assignee required) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: feature request

Comments

@SalmaSamy
Copy link
Contributor

SalmaSamy commented Sep 19, 2023

Vendor command fetches all external repositories into a folder specified by the flag --vendor_dir.

For the initial vendoring or updating existing vendor repositories the new command is:
bazel vendor --vendor_dir={vendordir}
With this all dependencies will be fetched to the specified directory. Also a target/s can be passed to limit the dependencies or --repo={repo_name} can be used to vendor a specific repo

The {vendordir} parameter can be either a full path or just a folder name, then the vendored repositories will be located under {workspace}/{vendordir}.


To perform a build using the vendored repositories, the same flag & value should be used:
bazel build {target} --vendor_dir={vendordir}
In this scenario, the vendor directory will be prioritized for repository retrieval. If the repository is not found or is outdated, the standard process will be followed, which involves checking cached repositories and fetching if not found.

Build & vendored repo is out-of-date/ not found:

  • If fetch is enabled, the repo will be fetched and used with a warning that a re-vendor is needed to update it under the vendor directory
  • If fetch is disabled, the vendored repo will be used as it is with a warning that it is out-of-date, or fail if it is not found

VENDOR.bazel file
A Starlark config file to allow controlling the vendored repos via:

  • ignore('repo_name','repo_name', ....) function
    Bazel will never vendor the repo or consider the vendor directory while building in vendor mode.
  • pin('repo_name','repo_name', ....) function
    Bazel will pin the contents of this repo, will not update it while vendoring, and will always use it as is when building in vendor mode

In progress:

  • Documentation
@SalmaSamy SalmaSamy added type: feature request P1 I'll work on this now. (Assignee required) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. area-Bzlmod Bzlmod-specific PRs, issues, and feature requests labels Sep 19, 2023
@Wyverald Wyverald added this to the 7.1.0 release blockers milestone Nov 16, 2023
@iancha1992 iancha1992 removed this from the 7.1.0 release blockers milestone Nov 29, 2023
@iancha1992
Copy link
Member

@bazel-io fork 7.1.0

@SalmaSamy
Copy link
Contributor Author

Design document

SalmaSamy added a commit that referenced this issue Jan 9, 2024
Vendor command fetches all external repositories into a folder specified by the flag --vendor_dir.
When building using the same flag & value the vendored repos are used as long as they are up to date.

Related #19563

PiperOrigin-RevId: 585105301
Change-Id: I08196c7ad924c1d22918ba09dba2ae774802a691
SalmaSamy added a commit that referenced this issue Jan 16, 2024
Vendor command fetches all external repositories into a folder specified by the flag --vendor_dir.
When building using the same flag & value the vendored repos are used as long as they are up to date.

Related #19563

PiperOrigin-RevId: 585105301
Change-Id: I08196c7ad924c1d22918ba09dba2ae774802a691
copybara-service bot pushed a commit that referenced this issue Jan 23, 2024
Now that we use the marker files for vendoring, each vendored repository has its marker file. To maintain platform independence, we should not include architecture details in these files. So that, if a repository is vendored on one platform and checked in, it should seamlessly work on other platforms, as long as it is up-to-date.

Additionally, this information was initially intended for a specific scenario involving Mac ships. But, we might not need them anymore!

PiperOrigin-RevId: 600743907
Change-Id: Icce5e44d9ca4c9ea16a363268d1e556d19a0397a
copybara-service bot pushed a commit that referenced this issue Jan 24, 2024
Vendor command fetches all external repositories into a folder specified by the flag --vendor_dir.
When building using the same flag & value the vendored repos are used as long as they are up to date.

For the initial vendoring or updating existing vendor repositories the new command vendor command is:
`bazel vendor --vendor_dir={vendordir}`

The {vendordir} parameter can be either a full path or just a folder name. Vendored repositories will be located under {workspace}/vendordir.

To perform a build using vendored repositories:
`bazel build {target} --vendor_dir={vendordir}`

In this scenario, the vendor directory will be prioritized for repository retrieval. If the repository is not found or is outdated, the standard process will be followed, which involves checking cached repositories and fetching if not found.

To exclude repositories from the vendoring process:
A file named ".vendorignore" is generated under the vendor directory. By adding the repository name to this file, the vendoring process will ignore it.
Also, any local or configure repos are ignored.

PiperOrigin-RevId: 601099450
Change-Id: I08196c7ad924c1d22918ba09dba2ae774802a691
copybara-service bot pushed a commit that referenced this issue Jan 25, 2024
Related #19563

Vendoring is not possible in offline mode; Verifing this flag before initiating any vendor-related tasks.

PiperOrigin-RevId: 601479912
Change-Id: I67ab3067cbd8c0726abd6006f4f00fe82bf31576
copybara-service bot pushed a commit that referenced this issue Feb 5, 2024
Update the build logic in vendor mode when `--nofetch` is passed:

If repo exists in the vendor directory
- If repo up-to-date ---> build
- else ---> warn that out-of-date version is used & build

else ---> fail

Working towards: #19563

PiperOrigin-RevId: 604405285
Change-Id: Ic6c7807296d039e1bd8970c3cde57e68f5e8de86
SalmaSamy added a commit that referenced this issue Feb 13, 2024
Vendor command fetches all external repositories into a folder specified by the flag --vendor_dir.
When building using the same flag & value the vendored repos are used as long as they are up to date.

For the initial vendoring or updating existing vendor repositories the new command vendor command is:
`bazel vendor --vendor_dir={vendordir}`

The {vendordir} parameter can be either a full path or just a folder name. Vendored repositories will be located under {workspace}/vendordir.

To perform a build using vendored repositories:
`bazel build {target} --vendor_dir={vendordir}`

In this scenario, the vendor directory will be prioritized for repository retrieval. If the repository is not found or is outdated, the standard process will be followed, which involves checking cached repositories and fetching if not found.

To exclude repositories from the vendoring process:
A file named ".vendorignore" is generated under the vendor directory. By adding the repository name to this file, the vendoring process will ignore it.
Also, any local or configure repos are ignored.

PiperOrigin-RevId: 601099450
Change-Id: I08196c7ad924c1d22918ba09dba2ae774802a691

# Conflicts:
#	src/test/java/com/google/devtools/build/lib/analysis/util/AnalysisTestCase.java
#	src/test/java/com/google/devtools/build/lib/analysis/util/ConfigurationTestCase.java
SalmaSamy added a commit that referenced this issue Feb 13, 2024
Related #19563

Vendoring is not possible in offline mode; Verifing this flag before initiating any vendor-related tasks.

PiperOrigin-RevId: 601479912
Change-Id: I67ab3067cbd8c0726abd6006f4f00fe82bf31576
SalmaSamy added a commit that referenced this issue Feb 13, 2024
Update the build logic in vendor mode when `--nofetch` is passed:

If repo exists in the vendor directory
- If repo up-to-date ---> build
- else ---> warn that out-of-date version is used & build

else ---> fail

Working towards: #19563

PiperOrigin-RevId: 604405285
Change-Id: Ic6c7807296d039e1bd8970c3cde57e68f5e8de86
SalmaSamy added a commit that referenced this issue Feb 13, 2024
Vendor command fetches all external repositories into a folder specified by the flag --vendor_dir.
When building using the same flag & value the vendored repos are used as long as they are up to date.

For the initial vendoring or updating existing vendor repositories the new command vendor command is:
`bazel vendor --vendor_dir={vendordir}`

The {vendordir} parameter can be either a full path or just a folder name. Vendored repositories will be located under {workspace}/vendordir.

To perform a build using vendored repositories:
`bazel build {target} --vendor_dir={vendordir}`

In this scenario, the vendor directory will be prioritized for repository retrieval. If the repository is not found or is outdated, the standard process will be followed, which involves checking cached repositories and fetching if not found.

To exclude repositories from the vendoring process:
A file named ".vendorignore" is generated under the vendor directory. By adding the repository name to this file, the vendoring process will ignore it.
Also, any local or configure repos are ignored.

PiperOrigin-RevId: 601099450
Change-Id: I08196c7ad924c1d22918ba09dba2ae774802a691

# Conflicts:
#	src/test/java/com/google/devtools/build/lib/analysis/util/AnalysisTestCase.java
#	src/test/java/com/google/devtools/build/lib/analysis/util/ConfigurationTestCase.java
SalmaSamy added a commit that referenced this issue Feb 13, 2024
Related #19563

Vendoring is not possible in offline mode; Verifing this flag before initiating any vendor-related tasks.

PiperOrigin-RevId: 601479912
Change-Id: I67ab3067cbd8c0726abd6006f4f00fe82bf31576
SalmaSamy added a commit that referenced this issue Feb 13, 2024
Update the build logic in vendor mode when `--nofetch` is passed:

If repo exists in the vendor directory
- If repo up-to-date ---> build
- else ---> warn that out-of-date version is used & build

else ---> fail

Working towards: #19563

PiperOrigin-RevId: 604405285
Change-Id: Ic6c7807296d039e1bd8970c3cde57e68f5e8de86
SalmaSamy added a commit that referenced this issue Feb 15, 2024
Vendor command fetches all external repositories into a folder specified by the flag --vendor_dir.
When building using the same flag & value the vendored repos are used as long as they are up to date.

For the initial vendoring or updating existing vendor repositories the new command vendor command is:
`bazel vendor --vendor_dir={vendordir}`

The {vendordir} parameter can be either a full path or just a folder name. Vendored repositories will be located under {workspace}/vendordir.

To perform a build using vendored repositories:
`bazel build {target} --vendor_dir={vendordir}`

In this scenario, the vendor directory will be prioritized for repository retrieval. If the repository is not found or is outdated, the standard process will be followed, which involves checking cached repositories and fetching if not found.

To exclude repositories from the vendoring process:
A file named ".vendorignore" is generated under the vendor directory. By adding the repository name to this file, the vendoring process will ignore it.
Also, any local or configure repos are ignored.

PiperOrigin-RevId: 601099450
Change-Id: I08196c7ad924c1d22918ba09dba2ae774802a691

# Conflicts:
#	src/test/java/com/google/devtools/build/lib/analysis/util/AnalysisTestCase.java
#	src/test/java/com/google/devtools/build/lib/analysis/util/ConfigurationTestCase.java
SalmaSamy added a commit that referenced this issue Feb 15, 2024
Related #19563

Vendoring is not possible in offline mode; Verifing this flag before initiating any vendor-related tasks.

PiperOrigin-RevId: 601479912
Change-Id: I67ab3067cbd8c0726abd6006f4f00fe82bf31576
copybara-service bot pushed a commit that referenced this issue Feb 15, 2024
PiperOrigin-RevId: 607312047
Change-Id: I363badb12d54005ab8fda48806a70549eaa788f3
SalmaSamy added a commit that referenced this issue Feb 15, 2024
PiperOrigin-RevId: 607312047
Change-Id: I363badb12d54005ab8fda48806a70549eaa788f3
SalmaSamy added a commit that referenced this issue Feb 15, 2024
Update the build logic in vendor mode when `--nofetch` is passed:

If repo exists in the vendor directory
- If repo up-to-date ---> build
- else ---> warn that out-of-date version is used & build

else ---> fail

Working towards: #19563

PiperOrigin-RevId: 604405285
Change-Id: Ic6c7807296d039e1bd8970c3cde57e68f5e8de86
@peakschris
Copy link

Is vendor mode supposed to include everything for an airgapped build? Because I'm using it with 7.1.1 and I'm finding a lot of repositories are not being included in vendor_dir. It is not clear to me from the design doc what the UI should be for creating a vendor_dir, and for building with it. And I'm not clear what parts are now implemented and tested and what is coming. Thanks for any clarity!

@peakschris
Copy link

@Wyverald I'm seeing issues with vendoring rules_helm (using release-7.2.0 latest). This module contains a symlink to a sub-repo, and the vendored symlink still points into the user cache, whilst I'd expect it to be rewritten to symlink into the vendor dir. Is this a known issue or should I open a new issue?

https://gitlab.industrysoftware.automation.siemens.com/devx/vendor/rules_helm/-/blame/main/helm/repositories.bzl#L130

@Wyverald
Copy link
Member

Wyverald commented May 15, 2024

@peakschris thanks for testing it out! Please file new issues for the symlink thing -- we're aware of it, but it's still nice to keep track of it explicitly.

EDIT:

Is vendor mode supposed to include everything for an airgapped build?

It should be. If it's missing, it's definitely something we should address at some point, so please feel free to file an issue

copybara-service bot pushed a commit that referenced this issue May 31, 2024
A Starlark config file to allow controlling the vendored repos via:
- ignore('repo_name','repo_name', ....) function -->
Bazel will never vendor the repo or consider this directory while building in vendor mode.
- pin('repo_name','repo_name', ....) function -->
Bazel will pin the contents of this repo, will not update it while vendoring, and will always use it as is when building in vendor mode

Co-authored-by: Yun Peng <pcloudy@google.com>
PiperOrigin-RevId: 639000162
Change-Id: I278359f6e92eab290dac9cc4ef3136aa140cf8ba
copybara-service bot pushed a commit that referenced this issue Jun 11, 2024
This drastically improves the speed of vendoring external repositories.

Related: #19563

Closes #22668.

PiperOrigin-RevId: 642338030
Change-Id: Idcba16c491711cf8fa6637d1e9c42cfc65e87599
meteorcloudy added a commit to meteorcloudy/bazel that referenced this issue Jun 18, 2024
A Starlark config file to allow controlling the vendored repos via:
- ignore('repo_name','repo_name', ....) function -->
Bazel will never vendor the repo or consider this directory while building in vendor mode.
- pin('repo_name','repo_name', ....) function -->
Bazel will pin the contents of this repo, will not update it while vendoring, and will always use it as is when building in vendor mode

Co-authored-by: Yun Peng <pcloudy@google.com>
PiperOrigin-RevId: 639000162
Change-Id: I278359f6e92eab290dac9cc4ef3136aa140cf8ba
meteorcloudy added a commit to meteorcloudy/bazel that referenced this issue Jun 18, 2024
This drastically improves the speed of vendoring external repositories.

Related: bazelbuild#19563

Closes bazelbuild#22668.

PiperOrigin-RevId: 642338030
Change-Id: Idcba16c491711cf8fa6637d1e9c42cfc65e87599
copybara-service bot pushed a commit that referenced this issue Jul 9, 2024
Repo wasn't vendored as expected due to wrong SkyValue cache caused by incorrect equals function.

Related: #19563

Closes #22953.

PiperOrigin-RevId: 650648957
Change-Id: Id31aa7d6f9bcbe2e3eb9e556ae31b3b8e42436bf
bazel-io pushed a commit to bazel-io/bazel that referenced this issue Jul 9, 2024
Repo wasn't vendored as expected due to wrong SkyValue cache caused by incorrect equals function.

Related: bazelbuild#19563

Closes bazelbuild#22953.

PiperOrigin-RevId: 650648957
Change-Id: Id31aa7d6f9bcbe2e3eb9e556ae31b3b8e42436bf
github-merge-queue bot pushed a commit that referenced this issue Jul 10, 2024
Repo wasn't vendored as expected due to wrong SkyValue cache caused by
incorrect equals function.

Related: #19563

Closes #22953.

PiperOrigin-RevId: 650648957
Change-Id: Id31aa7d6f9bcbe2e3eb9e556ae31b3b8e42436bf

Commit
076bbbb

Co-authored-by: Yun Peng <pcloudy@google.com>
@meteorcloudy meteorcloudy self-assigned this Jul 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-Bzlmod Bzlmod-specific PRs, issues, and feature requests P1 I'll work on this now. (Assignee required) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: feature request
Projects
Status: In Progress
Development

No branches or pull requests

8 participants