Generate a lockfile for the distribution archive on the fly #21302
Conversation
The MODULE.bazel.lock file we have in our source tree is generated by the version of Bazel specified in the .bazelversion file. We currently use this lockfile for our distribution archives, which means whenever we increment the lockfile version, we need to manually transform the checked-in lockfile to make it work with HEAD Bazel too. This commit generates a lockfile for HEAD Bazel on the fly and uses that for the distribution archive. This lockfile doesn't have any module extension content, since we only need to make sure that no network access happens during tests that use the distribution archive. See #21283 (comment) for more context.
github-actions
bot
added
the
awaiting-review
|
This is certainly simpler than maintaining a dist lockfile in the source tree, but it does mean we still access the internet during the build step (to generate the dist lockfile). That is probably better than accessing the internet during the test step (fewer concurrent accesses?), and can be mitigated by @fmeum's new lockfile format and/or cloning the BCR during CI setup. |
default output base directory not writable?
|
OK, this doesn't work. Accessing the registry during build really does mess certain jobs up. :/ We need the mitigations before this PR. |
The failure I see is: Shouldn't this be solved by |
hmm, on the genrule you mean? I thought this was because of "too many concurrent internet accesses" or whatever, since some shards did pass... but let me try that. |
This didn't seem to help. Some shards still fail, and some still pass. |
iancha1992
added
the
team-OSS
meteorcloudy
left a comment
meteorcloudy
left a comment
There was a problem hiding this comment.
Thanks, I think this should work!
|
thanks, |
changes from PR #21302) The MODULE.bazel.lock file we have in our source tree is generated by the version of Bazel specified in the .bazelversion file. We currently use this lockfile for our distribution archives, which means whenever we increment the lockfile version, we need to manually transform the checked-in lockfile to make it work with HEAD Bazel too. This commit generates a lockfile for HEAD Bazel on the fly and uses that for the distribution archive. This lockfile doesn't have any module extension content, since we only need to make sure that no network access happens during tests that use the distribution archive. See #21283 (comment) for more context. Change-Id: I5266bd1caf2e4cc3d7d18cb8695af73488064ae1 Signed-off-by: Xudong Yang <[email protected]>
github-actions
bot
removed
the
awaiting-review
changes from PR #21302) The MODULE.bazel.lock file we have in our source tree is generated by the version of Bazel specified in the .bazelversion file. We currently use this lockfile for our distribution archives, which means whenever we increment the lockfile version, we need to manually transform the checked-in lockfile to make it work with HEAD Bazel too. This commit generates a lockfile for HEAD Bazel on the fly and uses that for the distribution archive. This lockfile doesn't have any module extension content, since we only need to make sure that no network access happens during tests that use the distribution archive. See #21283 (comment) for more context. Change-Id: I5266bd1caf2e4cc3d7d18cb8695af73488064ae1 Signed-off-by: Xudong Yang <[email protected]>
The MODULE.bazel.lock file we have in our source tree is generated by the version of Bazel specified in the .bazelversion file. We currently use this lockfile for our distribution archives, which means whenever we increment the lockfile version, we need to manually transform the checked-in lockfile to make it work with HEAD Bazel too. This commit generates a lockfile for HEAD Bazel on the fly and uses that for the distribution archive. This lockfile doesn't have any module extension content, since we only need to make sure that no network access happens during tests that use the distribution archive. See #21283 (comment) for more context. Closes #21302. PiperOrigin-RevId: 606731749 Change-Id: If1f2b23066428b199e646059c76fa44ecfd2044a
…21338) The MODULE.bazel.lock file we have in our source tree is generated by the version of Bazel specified in the .bazelversion file. We currently use this lockfile for our distribution archives, which means whenever we increment the lockfile version, we need to manually transform the checked-in lockfile to make it work with HEAD Bazel too. This commit generates a lockfile for HEAD Bazel on the fly and uses that for the distribution archive. This lockfile doesn't have any module extension content, since we only need to make sure that no network access happens during tests that use the distribution archive. See #21283 (comment) for more context. Closes #21302. --------- Signed-off-by: Xudong Yang <[email protected]>
|
The changes in this PR have been included in Bazel 7.1.0 RC1. Please test out the release candidate and report any issues as soon as possible. If you're using Bazelisk, you can point to the latest RC by setting USE_BAZEL_VERSION=last_rc. |
The MODULE.bazel.lock file we have in our source tree is generated by the version of Bazel specified in the .bazelversion file. We currently use this lockfile for our distribution archives, which means whenever we increment the lockfile version, we need to manually transform the checked-in lockfile to make it work with HEAD Bazel too.
This commit generates a lockfile for HEAD Bazel on the fly and uses that for the distribution archive. This lockfile doesn't have any module extension content, since we only need to make sure that no network access happens during tests that use the distribution archive. See #21283 (comment) for more context.