[6.6.0] Add dummy //:maven-srcs target for 6.6.0 release #28208
Closed
+13
−5
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fixes the following Rocky Linux 8 Bazel release job failure described in bazelbuild#27463 (comment): ```txt ERROR: Skipping ':maven-srcs': no such target '//:maven-srcs': target 'maven-srcs' not declared in package '' defined by /workdir/BUILD WARNING: Target pattern parsing failed. ERROR: no such target '//:maven-srcs': target 'maven-srcs' not declared in package '' defined by /workdir/BUILD ``` Reproduced and confirmed the fix by executing the failing release job command locally: ```txt ./bazel-bin/src/bazel build --nobuild \ :bazel-srcs :bootstrap-jars :maven-srcs //src:derived_java_srcs ``` Part of bazelbuild#28177. --- Background from: - bazelbuild#27463 (comment) `bazelbuild/continuous-integration/pipelines/bazel-release.yml` defines the failing Rocky Linux 8 job. (This was a CentOS 7 job prior to bazelbuild/continuous-integration#2281.) - https://github.com/bazelbuild/continuous-integration/blob/agent-0.2.7/pipelines/bazel-release.yml#L85 bazelbuild/bazel@3d7937e introduced the `//:maven-srcs` target in Bazel 7.0.0. All the other targets in the failing `bazel build` invocation exist on the Bazel 6.6.0 branch. bazelbuild/continuous-integration@14a0378 added the `//:maven-srcs` target to this job as an attempt to fix `MODULE.bazel.lock` generation. Neither the lock file nor the `//:maven-srcs` target itself should have any bearing on the Bazel 6.6.0 release. This dummy target fixes the build failure and allows the release to proceed.
github-actions
bot
added
the
awaiting-review
This was referenced Jan 9, 2026
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
iancha1992
added
the
team-OSS
Author
|
@iancha1992 @meteorcloudy The Windows builds all appear to have failed in the same, arcane way unrelated to this change: archive.extract(member, dest_dir)
Setting up comparison repository...
A subdirectory or file C:\b already exists.
Cannot create a file when that file already exists.
Traceback (most recent call last):
File "c:\b\bk-windows-kmds\bazel\bazel-bazel-github-presubmit\bazelci.py", line 4695, in <module>
sys.exit(main())
^^^^^^
File "c:\b\bk-windows-kmds\bazel\bazel-bazel-github-presubmit\bazelci.py", line 4663, in main
execute_commands(
File "c:\b\bk-windows-kmds\bazel\bazel-bazel-github-presubmit\bazelci.py", line 1330, in execute_commands
build_targets, test_targets, coverage_targets, index_targets = calculate_targets(
^^^^^^^^^^^^^^^^^^
File "c:\b\bk-windows-kmds\bazel\bazel-bazel-github-presubmit\bazelci.py", line 2254, in calculate_targets
filter_unchanged_targets(
File "c:\b\bk-windows-kmds\bazel\bazel-bazel-github-presubmit\bazelci.py", line 2417, in filter_unchanged_targets
ws_setup_func(False)
File "c:\b\bk-windows-kmds\bazel\bazel-bazel-github-presubmit\bazelci.py", line 1306, in PrepareRepoInCwd
execute_batch_commands(task_config.get("batch_commands", None), print_cmd_groups)
File "c:\b\bk-windows-kmds\bazel\bazel-bazel-github-presubmit\bazelci.py", line 1821, in execute_batch_commands
return subprocess.run(batch_commands, shell=True, check=True, env=os.environ).returncode
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\python3\Lib\subprocess.py", line 571, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command 'mkdir C:\b&mklink /J C:\b\bazeltest_external %OUTPUT_BASE:/=\%\external' returned non-zero exit status 1. |
iancha1992
changed the title
Author
|
Retrying the Windows shards didn't seem to help. It seems like the Windows build VMs are wedged, since the |
Member
|
I'm fixing the release pipeline for 6.6.0, this may not be needed. |
github-actions
bot
removed
the
awaiting-review
mbland
deleted the
6.6.0-dummy-maven-srcs-to-fix-rocky-linux-release-job
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes the following Rocky Linux 8 Bazel release job failure described in #27463 (comment):
Reproduced and confirmed the fix by executing the failing release job command locally:
Part of #28177.
Background from:
bazelbuild/continuous-integration/pipelines/bazel-release.ymldefines the failing Rocky Linux 8 job. (This was a CentOS 7 job prior to bazelbuild/continuous-integration#2281.)3d7937e introduced the
//:maven-srcstarget in Bazel 7.0.0. All the other targets in the failingbazel buildinvocation exist on the Bazel 6.6.0 branch.bazelbuild/continuous-integration@14a0378 added the
//:maven-srcstarget to this job as an attempt to fixMODULE.bazel.lockgeneration.Neither the lock file nor the
//:maven-srcstarget itself should have any bearing on the Bazel 6.6.0 release. This dummy target fixes the build failure and allows the release to proceed.