jetbrains / bazel-bsp Goto Github PK

View Code? Open in Web Editor NEW

166.0 26.0 46.0 5.82 MB

An implementation of the Build Server Protocol for Bazel

Home Page: https://youtrack.jetbrains.com/issues/BAZEL

License: Apache License 2.0

Starlark 9.81% Java 1.35% Scala 0.17% C++ 0.01% Kotlin 88.35% Python 0.24% Rust 0.06%

bsp-server bazel-bsp compilation-diagnostics diagnostics bsp build-server-protocol

bazel-bsp's Introduction

Bazel BSP

An implementation of the Build Server Protocol for Bazel.

Supported languages

Java
Kotlin
Scala
Python
Thrift
Rust

Installation

Easy way (coursier)

Have coursier installed
Run in the directory where Bazel BSP should be installed:

cs launch org.jetbrains.bsp:bazel-bsp:<version> -M org.jetbrains.bsp.bazel.install.Install -- --targets //...

Please check release to find the newest available version 3. Add bsp generated folders to your .gitignore: .bsp and .bazelbsp

More difficult way (from sources)

Might be useful during development

Using install script

Be inside this project
Run bazel run //install -- <installer flags> (--help is available)

Using coursier

Have coursier installed
Be inside this project
Change the project version - maven_coordinates attribute in the server/src/main/kotlin/org/jetbrains/bsp/bazel/BUILD file
Publish a new version:

bazel run --stamp --define "maven_repo=file://$HOME/.m2/repository" //server/src/main/kotlin/org/jetbrains/bsp/bazel:bsp.publish

Enter directory where Bazel BSP should be installed
Install your version:

cs launch -r m2Local org.jetbrains.bsp:bazel-bsp:<your version> -M org.jetbrains.bsp.bazel.install.Install

Project Views

In order to work on huge monorepos you might want to specify directories and targets to work on. To address this issue, Bazel BSP supports (partly) the Project Views introduced by Google.

Check project view readme for more info.

Tests

Unit tests

Run bazel test //... to execute all the unit tests.

End-to-end tests

e2e directory contains end-2-end tests that check various scenarios of server usage.

Tests are marked as manual so they won't be executed on bazel test //... but you can run all of them using: bazel test //e2e:all_tests

In order to run a specific test with specific bazel version you can use: bazel test //e2e:<test name>_bazel_<bazel version_major>_x (bazel test //e2e:<test name>_bazel_current to use bazel version defined in .bazelversion file) or bazel test //e2e:<test name>_bazel_<bazel version>

e.g. bazel test //e2e:sample_repo_test_bazel_6_x or bazel test //e2e:sample_repo_test_bazel_current or bazel test //e2e:sample_repo_test_bazel_6_4_0

In order to run a specific test with all bazel versions you can use: bazel test //e2e:<test name>

e.g. bazel test //e2e:sample_repo_test

Contributing

Want to contribute? Great! Follow these rules.

bazel-bsp's People

Contributors

Stargazers

Watchers

bazel-bsp's Issues

Project Views should be loaded on initial call instead of the server initialization

currently, project view file (including entire configuration) is loaded during server installation. It would be nice if this happened during first call from the client and on the reload call. Then user could change configuration and reload the project without reinstalling server. Maybe only used file name should be set during installation.

Check if generated sources are properly picked up

There are several mentions as to how generated sources exist within bazel scope, but I haven't been able to find any real example of them to test it against my solution. A workspace with generated sources should be found and properly tested against

get rid of main class in coursier installation command

currently:

cs launch org.jetbrains.bsp:bazel-bsp:<version> -M org.jetbrains.bsp.bazel.install.Install

should be:

cs launch org.jetbrains.bsp:bazel-bsp:<version>

BSP server fails with an unclear message when there's no aspects.bzl in .bazelbsp folder

Analyzing: target //:java_deps (0 packages loaded, 0 targets configured)
ERROR: Label '//.bazelbsp:aspects.bzl' is invalid because '.bazelbsp' is not a package; perhaps you meant to put the colon here: '//:.bazelbsp/aspects.bzl'?
ERROR: Analysis of aspect '//.bazelbsp:aspects.bzl%print_aspect of //:java_deps' failed; build aborted: Label '//.bazelbsp:aspects.bzl' is invalid because '.bazelbsp' is not a package; perhaps you meant to put the colon here: '//:.bazelbsp/aspects.bzl'?
INFO: Elapsed time: 204.997s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 0 targets configured)
Command aborted with reason INCOMPLETE:
kwi 06, 2021 3:58:19 PM io.grpc.internal.SerializingExecutor run

SEVERE: Exception while executing runnable io.grpc.internal.ServerImpl$JumpToApplicationThreadServerStreamListener$1MessagesAvailable@4bfef24a

java.lang.RuntimeException: Command aborted with reason INCOMPLETE: 

	at org.jetbrains.bsp.bazel.server.bep.BepServer.consumeAbortedEvent(BepServer.java:237)

	at org.jetbrains.bsp.bazel.server.bep.BepServer.processAbortedEvent(BepServer.java:226)

	at org.jetbrains.bsp.bazel.server.bep.BepServer.handleEvent(BepServer.java:103)

	at org.jetbrains.bsp.bazel.server.bep.BepStreamObserver.onNext(BepStreamObserver.java:28)

	at org.jetbrains.bsp.bazel.server.bep.BepStreamObserver.onNext(BepStreamObserver.java:9)

	at io.grpc.stub.ServerCalls$StreamingServerCallHandler$StreamingServerCallListener.onMessage(ServerCalls.java:251)

	at io.grpc.internal.ServerCallImpl$ServerStreamListenerImpl.messagesAvailableInternal(ServerCallImpl.java:309)

	at io.grpc.internal.ServerCallImpl$ServerStreamListenerImpl.messagesAvailable(ServerCallImpl.java:292)

	at io.grpc.internal.ServerImpl$JumpToApplicationThreadServerStreamListener$1MessagesAvailable.runInContext(ServerImpl.java:782)

	at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)

	at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:123)

	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)

	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)

	at java.base/java.lang.Thread.run(Thread.java:832)



Command aborted with reason INCOMPLETE:
kwi 06, 2021 3:58:20 PM io.grpc.internal.SerializingExecutor run

SEVERE: Exception while executing runnable io.grpc.internal.ServerImpl$JumpToApplicationThreadServerStreamListener$1MessagesAvailable@5118182b

java.lang.RuntimeException: Command aborted with reason INCOMPLETE: 

	at org.jetbrains.bsp.bazel.server.bep.BepServer.consumeAbortedEvent(BepServer.java:237)

	at org.jetbrains.bsp.bazel.server.bep.BepServer.processAbortedEvent(BepServer.java:226)

	at org.jetbrains.bsp.bazel.server.bep.BepServer.handleEvent(BepServer.java:103)

	at org.jetbrains.bsp.bazel.server.bep.BepStreamObserver.onNext(BepStreamObserver.java:28)

	at org.jetbrains.bsp.bazel.server.bep.BepStreamObserver.onNext(BepStreamObserver.java:9)

	at io.grpc.stub.ServerCalls$StreamingServerCallHandler$StreamingServerCallListener.onMessage(ServerCalls.java:251)

	at io.grpc.internal.ServerCallImpl$ServerStreamListenerImpl.messagesAvailableInternal(ServerCallImpl.java:309)

	at io.grpc.internal.ServerCallImpl$ServerStreamListenerImpl.messagesAvailable(ServerCallImpl.java:292)

	at io.grpc.internal.ServerImpl$JumpToApplicationThreadServerStreamListener$1MessagesAvailable.runInContext(ServerImpl.java:782)

	at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)

	at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:123)

	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)

	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)

	at java.base/java.lang.Thread.run(Thread.java:832)

running integration tests via bazel instead of bash

currently big tests / integration tests are run by bash script -- it would be nice to run them with bazel test ...

Also, they should use one of installation methods to test this process as well

More tests for ProjectView and related

Quite complicated logic, ProjectViewParser is tested, but the following logic isn't.

project is built around a fork of `rules_scala`

Project is built around a fork of rules_scala and not all of the changes are available in the main project.

Problem building rules_jvm_external

clone repo from https://github.com/bazelbuild/rules_jvm_external
import
try to build all targets

It will fail because some test targets are included:

Loading: 0 packages loaded
DEBUG: /private/var/tmp/_bazel_jast/46161c2ded187f0bd0ff099227d4841e/external/bazel_toolchains/rules/rbe_repo/version_check.bzl:68:14: 
Current running Bazel is ahead of bazel-toolchains repo. Please update your pin to bazel-toolchains repo in your WORKSPACE file.
DEBUG: /private/var/tmp/_bazel_jast/46161c2ded187f0bd0ff099227d4841e/external/bazel_toolchains/rules/rbe_repo/checked_in.bzl:125:14: buildkite_config not using checked in configs; Bazel version 3.5.0 was picked/selected but no checked in config was found in map {"0.20.0": ["8.0.0"], "0.21.0": ["8.0.0"], "0.22.0": ["8.0.0", "9.0.0"], "0.23.0": ["8.0.0", "9.0.0"], "0.23.1": ["8.0.0", "9.0.0"], "0.23.2": ["9.0.0"], "0.24.0": ["9.0.0"], "0.24.1": ["9.0.0"], "0.25.0": ["9.0.0"], "0.25.1": ["9.0.0"], "0.25.2": ["9.0.0"], "0.26.0": ["9.0.0"], "0.26.1": ["9.0.0"], "0.27.0": ["9.0.0"], "0.27.1": ["9.0.0"], "0.28.0": ["9.0.0"], "0.28.1": ["9.0.0"], "0.29.0": ["9.0.0"], "0.29.1": ["9.0.0", "10.0.0"], "1.0.0": ["9.0.0", "10.0.0"], "1.0.1": ["10.0.0"], "1.1.0": ["10.0.0"], "1.2.0": ["10.0.0"], "1.2.1": ["10.0.0"]}
Loading: 0 packages loaded
Loading: 
Loading: 0 packages loaded
DEBUG: /private/var/tmp/_bazel_jast/46161c2ded187f0bd0ff099227d4841e/external/bazel_toolchains/rules/rbe_repo/version_check.bzl:68:14: 
Current running Bazel is ahead of bazel-toolchains repo. Please update your pin to bazel-toolchains repo in your WORKSPACE file.
DEBUG: /private/var/tmp/_bazel_jast/46161c2ded187f0bd0ff099227d4841e/external/bazel_toolchains/rules/rbe_repo/checked_in.bzl:125:14: buildkite_config not using checked in configs; Bazel version 3.5.0 was picked/selected but no checked in config was found in map {"0.20.0": ["8.0.0"], "0.21.0": ["8.0.0"], "0.22.0": ["8.0.0", "9.0.0"], "0.23.0": ["8.0.0", "9.0.0"], "0.23.1": ["8.0.0", "9.0.0"], "0.23.2": ["9.0.0"], "0.24.0": ["9.0.0"], "0.24.1": ["9.0.0"], "0.25.0": ["9.0.0"], "0.25.1": ["9.0.0"], "0.25.2": ["9.0.0"], "0.26.0": ["9.0.0"], "0.26.1": ["9.0.0"], "0.27.0": ["9.0.0"], "0.27.1": ["9.0.0"], "0.28.0": ["9.0.0"], "0.28.1": ["9.0.0"], "0.29.0": ["9.0.0"], "0.29.1": ["9.0.0", "10.0.0"], "1.0.0": ["9.0.0", "10.0.0"], "1.0.1": ["10.0.0"], "1.1.0": ["10.0.0"], "1.2.0": ["10.0.0"], "1.2.1": ["10.0.0"]}
Analyzing: 96 targets (0 packages loaded, 0 targets configured)
Command aborted with reason ANALYSIS_FAILURE: in genrule rule //tests/unit/build_tests:strict_version_neg_0__deps: target '@strict_visibility_testing//:org_apache_tomcat_tomcat_api' is not visible from target '//tests/unit/build_tests:strict_version_neg_0__deps'. Check the visibility declaration of the former target if you think the dependency is legitimate
Command aborted with reason ANALYSIS_FAILURE: in genrule rule //tests/unit/build_tests:strict_version_neg_0__deps: target '@strict_visibility_testing//:org_apache_tomcat_tomcat_api' is not visible from target '//tests/unit/build_tests:strict_version_neg_0__deps'. Check the visibility declaration of the former target if you think the dependency is legitimate
Command aborted with reason ANALYSIS_FAILURE: in genrule rule //tests/unit/build_tests:strict_version_neg_0__deps: target '@strict_visibility_testing//:org_apache_tomcat_tomcat_api' is not visible from target '//tests/unit/build_tests:strict_version_neg_0__deps'. Check the visibility declaration of the former target if you think the dependency is legitimate
Command aborted with reason ANALYSIS_FAILURE: in genrule rule //tests/unit/build_tests:strict_version_neg_0__deps: target '@strict_visibility_testing//:org_apache_tomcat_tomcat_api' is not visible from target '//tests/unit/build_tests:strict_version_neg_0__deps'. Check the visibility declaration of the former target if you think the dependency is legitimate
Command aborted with reason ANALYSIS_FAILURE: in genrule rule //tests/unit/build_tests:strict_version_neg_0__deps: target '@strict_visibility_testing//:org_apache_tomcat_tomcat_api' is not visible from target '//tests/unit/build_tests:strict_version_neg_0__deps'. Check the visibility declaration of the former target if you think the dependency is legitimate
Command aborted with reason ANALYSIS_FAILURE: in genrule rule //tests/unit/build_tests:strict_version_neg_0__deps: target '@strict_visibility_testing//:org_apache_tomcat_tomcat_api' is not visible from target '//tests/unit/build_tests:strict_version_neg_0__deps'. Check the visibility declaration of the former target if you think the dependency is legitimate
ERROR: /Users/jast/workspace/rules_jvm_external/tests/unit/build_tests/BUILD:66:11: in genrule rule //tests/unit/build_tests:strict_version_neg_0__deps: target '@strict_visibility_testing//:org_apache_tomcat_tomcat_api' is not visible from target '//tests/unit/build_tests:strict_version_neg_0__deps'. Check the visibility declaration of the former target if you think the dependency is legitimate
INFO: Elapsed time: 0.077s
Loading: 0 packages loaded
DEBUG: /private/var/tmp/_bazel_jast/46161c2ded187f0bd0ff099227d4841e/external/bazel_toolchains/rules/rbe_repo/version_check.bzl:68:14:
FAILED: Build did NOT complete successfully (1 packages loaded, 2 targets configured)
INFO: 0 processes.
ERROR: The Build Event Protocol upload failed: Not retrying publishBuildEvents, no more attempts left: status='Status{code=UNKNOWN, description=null, cause=null}' UNKNOWN: UNKNOWN UNKNOWN: UNKNOWN
DEBUG: /private/var/tmp/_bazel_jast/46161c2ded187f0bd0ff099227d4841e/external/bazel_toolchains/rules/rbe_repo/checked_in.bzl:125:14: buildkite_config not using checked in configs; Bazel version 3.5.0 was picked/selected but no checked in config was found in map {"0.20.0": ["8.0.0"], "0.21.0": ["8.0.0"], "0.22.0": ["8.0.0", "9.0.0"], "0.23.0": ["8.0.0", "9.0.0"], "0.23.1": ["8.0.0", "9.0.0"], "0.23.2": ["9.0.0"], "0.24.0": ["9.0.0"], "0.24.1": ["9.0.0"], "0.25.0": ["9.0.0"], "0.25.1": ["9.0.0"], "0.25.2": ["9.0.0"], "0.26.0": ["9.0.0"], "0.26.1": ["9.0.0"], "0.27.0": ["9.0.0"], "0.27.1": ["9.0.0"], "0.28.0": ["9.0.0"], "0.28.1": ["9.0.0"], "0.29.0": ["9.0.0"], "0.29.1": ["9.0.0", "10.0.0"], "1.0.0": ["9.0.0", "10.0.0"], "1.0.1": ["10.0.0"], "1.1.0": ["10.0.0"], "1.2.0": ["10.0.0"], "1.2.1": ["10.0.0"]}
Analyzing: 96 targets (0 packages loaded, 0 targets configured)
Loading:
Current running Bazel is ahead of bazel-toolchains repo. Please update your pin to bazel-toolchains repo in your WORKSPACE file.
ERROR: Analysis of target '//tests/unit/build_tests:strict_version_neg' failed; build aborted: Analysis failed

Building the targets separately from command line yields essentially the same error:

> bazel query //... | xargs bazel build
Loading: 0 packages loaded
DEBUG: /private/var/tmp/_bazel_jast/46161c2ded187f0bd0ff099227d4841e/external/bazel_toolchains/rules/rbe_repo/version_check.bzl:68:14:
Current running Bazel is ahead of bazel-toolchains repo. Please update your pin to bazel-toolchains repo in your WORKSPACE file.
DEBUG: /private/var/tmp/_bazel_jast/46161c2ded187f0bd0ff099227d4841e/external/bazel_toolchains/rules/rbe_repo/checked_in.bzl:125:14: buildkite_config not using checked in configs; Bazel version 3.5.0 was picked/selected but no checked in config was found in map {"0.20.0": ["8.0.0"], "0.21.0": ["8.0.0"], "0.22.0": ["8.0.0", "9.0.0"], "0.23.0": ["8.0.0", "9.0.0"], "0.23.1": ["8.0.0", "9.0.0"], "0.23.2": ["9.0.0"], "0.24.0": ["9.0.0"], "0.24.1": ["9.0.0"], "0.25.0": ["9.0.0"], "0.25.1": ["9.0.0"], "0.25.2": ["9.0.0"], "0.26.0": ["9.0.0"], "0.26.1": ["9.0.0"], "0.27.0": ["9.0.0"], "0.27.1": ["9.0.0"], "0.28.0": ["9.0.0"], "0.28.1": ["9.0.0"], "0.29.0": ["9.0.0"], "0.29.1": ["9.0.0", "10.0.0"], "1.0.0": ["9.0.0", "10.0.0"], "1.0.1": ["10.0.0"], "1.1.0": ["10.0.0"], "1.2.0": ["10.0.0"], "1.2.1": ["10.0.0"]}
Loading: 0 packages loaded
Loading: 0 packages loaded
DEBUG: /private/var/tmp/_bazel_jast/46161c2ded187f0bd0ff099227d4841e/external/bazel_toolchains/rules/rbe_repo/version_check.bzl:68:14:
Current running Bazel is ahead of bazel-toolchains repo. Please update your pin to bazel-toolchains repo in your WORKSPACE file.
DEBUG: /private/var/tmp/_bazel_jast/46161c2ded187f0bd0ff099227d4841e/external/bazel_toolchains/rules/rbe_repo/checked_in.bzl:125:14: buildkite_config not using checked in configs; Bazel version 3.5.0 was picked/selected but no checked in config was found in map {"0.20.0": ["8.0.0"], "0.21.0": ["8.0.0"], "0.22.0": ["8.0.0", "9.0.0"], "0.23.0": ["8.0.0", "9.0.0"], "0.23.1": ["8.0.0", "9.0.0"], "0.23.2": ["9.0.0"], "0.24.0": ["9.0.0"], "0.24.1": ["9.0.0"], "0.25.0": ["9.0.0"], "0.25.1": ["9.0.0"], "0.25.2": ["9.0.0"], "0.26.0": ["9.0.0"], "0.26.1": ["9.0.0"], "0.27.0": ["9.0.0"], "0.27.1": ["9.0.0"], "0.28.0": ["9.0.0"], "0.28.1": ["9.0.0"], "0.29.0": ["9.0.0"], "0.29.1": ["9.0.0", "10.0.0"], "1.0.0": ["9.0.0", "10.0.0"], "1.0.1": ["10.0.0"], "1.1.0": ["10.0.0"], "1.2.0": ["10.0.0"], "1.2.1": ["10.0.0"]}
ERROR: /Users/jast/workspace/rules_jvm_external/tests/unit/build_tests/BUILD:66:11: in genrule rule //tests/unit/build_tests:strict_version_neg_0__deps: target '@strict_visibility_testing//:org_apache_tomcat_tomcat_api' is not visible from target '//tests/unit/build_tests:strict_version_neg_0__deps'. Check the visibility declaration of the former target if you think the dependency is legitimate
ERROR: Analysis of target '//tests/unit/build_tests:strict_version_neg' failed; build aborted: Analysis failed
INFO: Elapsed time: 0.089s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (1 packages loaded, 3 targets configured)
    currently loading: @local_config_cc//
    Fetching @kt_java_stub_template; fetching

index query photo response parsing

from TODO list

Moving methods from ParsingUtils closer to where they're used

Suggested by @abrams27
#24 (comment)

Action graph parser v2 is quite slow

it is visible also in the CI - it is the slowest job

installation targets are a bit ambiguous

we have multiple "*-install" targets

Add BSP debug/run support

https://github.com/scalacenter/scala-debug-adapter was recently released/split out from bloop and has an example debug client plugin for SBT as a reference. This should also be usable by this bazel-bsp project.

Integration tests upgrade

Integration tests need again refactor - the logic is too ambiguous again + lets try to change execution of tests - instead of bash script, maybe bazel test ...

todo:

move tests to the separate module - e2e
make tests more readable - one big file with targets and similar is ugly
run tests via bazel
separate every test into separate target

Notify the client when server initialization fails

In one of the previous PRs (#18) I moved the code responsible for fetching bazel data (workspace root etc.) to the constructor of BspServer. It simplified the logic, but now I realized it also has an unfortunate effect: when Bazel fails to fetch this data with bazel info, the whole server crashed before it is possible to notify the client. Such crash can happen for example because of a typo in the WORKSPACE file, so it would be a totally reasonable thing to do to forward the failure massage to the client.

TODO:

change the code so that bazel data is fetched during handling of the initial client request
if it fails, relay the message generated by bazel (i.e. the client should receive the full output of the /usr/bin/bazel info call)
test this behavior of course ;_;

Use an aspect output group to obtain dependencies

Currently the buildTarget/dependencySources request parses the output of an aspect. Even though this is stable, there would be some value in substituting this with an Output Group, like this example

Installing process simplification

Installation is an unpredictable process and a bit ambiguous:

dependencies version check
coursier installation
installing local version should be done with a single script
installing in any directory should be also done with only single script (maybe the same?)
more logs during installation should be produced
update README

junit 5

i tried to switch to junit 5, but it creates strange errors

Loading: 0 packages loaded

during import usually multiple lines (almost half of logs) contain Loading: 0 packages loaded -- it shouldn't be shown for the clarity of logs

Semantic Version format `*-homebrew`

Parser doesnt support more "sophisticated" versions:

bazel version
Build label: 4.1.0-homebrew
Build target: bazel-out/darwin-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Tue Jan 1 00:00:00 1980 (315532800)
Build timestamp: 315532800
Build timestamp as int: 315532800

causes:

java.lang.IllegalArgumentException: Invalid version format

	at org.jetbrains.bsp.bazel.server.bazel.data.SemanticVersion.<init>(SemanticVersion.java:27)

	at org.jetbrains.bsp.bazel.server.bazel.data.SemanticVersion.fromReleaseData(SemanticVersion.java:51)

	at org.jetbrains.bsp.bazel.server.bazel.data.BazelData.<init>(BazelData.java:21)

	at org.jetbrains.bsp.bazel.server.bazel.BazelDataResolver.resolveBazelData(BazelDataResolver.java:30)

	at org.jetbrains.bsp.bazel.server.BazelBspServer.<init>(BazelBspServer.java:48)

	at org.jetbrains.bsp.bazel.server.ServerInitializer.main(ServerInitializer.java:49)

solution should be quite easy - update validation regex, but are there any other correct version formats not considered?

blocks: #64

buildTargetScalacOptions and buildTargetJavacOptions are returning empty

After working on extending the BSP testkit for the extension methods, I decided to test the sample repo used here against those methods. It would seem both buildTargetScalacOptions and buildTargetJavacOptions are returning empty responses.

We should try and see what is going on there. Furthermore, after the testkit update is merged, we should take the chance to also make sure those requests are tested.

"Invalid version format" when using Bazel rolling releases

Hi,

I tried to use the Bazel BSP feature in IntellIJ IDEA 2021.2.1 (UE) with Scala plugin 2021.2.17 and Bazel itself as the project.

When I use Bazel rolling releases, the plug-in crashes with an "Invalid version format" exception in this line: https://github.com/JetBrains/bazel-bsp/blob/dev/bazelrunner/src/main/java/org/jetbrains/bsp/bazel/bazelrunner/data/SemanticVersion.java#L34

I think this is because the regex used rejects the version number. Maybe you could use the regex given in the SemVer 2.0 spec to parse the string instead? See: https://semver.org/#is-there-a-suggested-regular-expression-regex-to-check-a-semver-string

Details:

$ export USE_BAZEL_VERSION=rolling
$ bazel version
Bazelisk version: development
Build label: 5.0.0-pre.20210817.2
Build target: bazel-out/darwin_arm64-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Wed Aug 25 11:16:44 2021 (1629890204)
Build timestamp: 1629890204
Build timestamp as int: 1629890204

Stack trace:

java.lang.IllegalArgumentException: Invalid version format
	at org.jetbrains.bsp.bazel.server.bazel.data.SemanticVersion.<init>(SemanticVersion.java:34)
	at org.jetbrains.bsp.bazel.server.bazel.data.SemanticVersion.fromReleaseData(SemanticVersion.java:56)
	at org.jetbrains.bsp.bazel.server.bazel.data.BazelData.<init>(BazelData.java:21)
	at org.jetbrains.bsp.bazel.server.bazel.BazelDataResolver.resolveBazelData(BazelDataResolver.java:30)
	at org.jetbrains.bsp.bazel.server.BazelBspServer.<init>(BazelBspServer.java:48)
	at org.jetbrains.bsp.bazel.server.ServerInitializer.main(ServerInitializer.java:49)

Fake Bazel specific files module

Currently bazel specific files (WORKSPACE, .bazelrc) are outside of project - what is annoying when editing.

The solution could be adding "fake" module/target for those files (excluding ones from .gitignore)

Implement `buildTarget/scalaTestClasses`

No logging to the client

The current development version of bazel bsp has lost most of its logging to the build window. More feedback to the user should be added back.

Caching and Indexing of the Action Graph

Currently the action graph is consumed everytime the request is being handled. This graph can be indexed and cached in order to improve performance.

more progress notifications

from TODO list

Failed to import dependencies from rules_jvm_external

Steps to reproduce:

Open the rules_jvm_external repository (https://github.com/bazelbuild/rules_jvm_external/tree/4.0) with bazel bsp
Open a files with maven dependencies, such as MavenPublisher.java

Its external dependencies are not found

Server not responding to initialize request.

Hello! Thanks for the great work you've put into this so far. I've been itching to try and see how this would work with Metals, so I dug in a bit today but hit a couple snags that I was hoping someone might have some more insight into.

Firstly I tried the readme instructions with coursier launch -r sonatype:snapshots org.jetbrains.bsp:bazel-bsp:0.1.0 -M org.jetbrains.bsp.bazel.Install, however there seems to have been a lot of work since 0.1.0 was release. Plus, when trying that version I get a lot of internal errors like:

(Note these are traces from the Metals perspective)

[Trace - 11:48:47 AM] Received notification 'build/logMessage'
Params: {
  "type": 1,
  "message": "Command aborted with reason LOADING_FAILURE: error loading package \u0027bazel-bazel_scala_example/external/io_bazel_rules_scala/scala_proto\u0027: Label \u0027//scala_proto:scala_proto_toolchain.bzl\u0027 is invalid because \u0027scala_proto\u0027 is not a package; perhaps you meant to put the colon here: \u0027//:scala_proto/scala_proto_toolchain.bzl\u0027?"
}
...

[Trace - 11:48:48 AM] Received notification 'build/logMessage'
Params: {
  "type": 4,
  "message": "Loading: 0 packages loaded\nERROR: Error while parsing \u0027()\u0027: syntax error at \u0027)\u0027\nLoading: 0 packages loaded"
}


[Trace - 11:48:48 AM] Received notification 'build/logMessage'
Params: {
  "type": 1,
  "message": "Command aborted with reason INTERNAL: "
...

I sort of assumed that these were coming from the bsp side mainly due to me not defining anything with proto. Anyways, this led me to then try out the latest dev branch using buildAndRunLocally.sh and pointing it to a very minimal example project.

The .bsp/bazelbsp.json file does appear to be created fine:

{
  "name": "bazelbsp",
  "argv": [
    "/usr/local/Cellar/openjdk@11/11.0.10/libexec/openjdk.jdk/Contents/Home/bin/java",
    "-classpath",
    "...super long classpath",
    "org.jetbrains.bsp.bazel.server.ServerInitializer",
    "/usr/local/bin/bazel"
  ],
  "version": "0.0.0",
  "bspVersion": "2.0.0",
  "languages": [
    "scala",
    "java",
    "kotlin"
  ]
}

When Metals starts up and attempts to initiate the BSP process the request to initialize is sent in:

[Trace - 11:57:34 AM] Sending request 'build/initialize - (1)'
Params: {
  "rootUri": "file:///Users/ckipp/Documents/scala-workspace/metals_bazel_tester/",
  "displayName": "Metals",
  "version": "0.10.5-SNAPSHOT",
  "bspVersion": "2.0.0-M13",
  "capabilities": {
    "languageIds": [
      "scala"
    ]
  },
  "data": {
    "semanticdbVersion": "4.4.21",
    "supportedScalaVersions": [
      "2.13.6",
      "2.12.14",
      "2.12.13",
      "2.12.12",
      "2.12.11",
      "2.12.10",
      "2.13.3",
      "2.13.4",
      "2.13.5",
      "2.11.12",
      "2.12.8",
      "2.12.9",
      "2.13.0",
      "2.13.1",
      "2.13.2"
    ]
  }
}

But it seems to never succeed, no response is sent back, and times out. Looking at the .bazelbsp/bazelbsp.all.log file the only thing I continually see is:

2021-06-16 11:57:54.918 [main] INFO    org.jetbrains.bsp.bazel.server.bazel.BazelRunner - Waiting for bazel - command: info, flags: [], arguments: [bazel-bin]
2021-06-16 11:57:54.918 [main] INFO    org.jetbrains.bsp.bazel.server.bazel.BazelRunner - Running: [/usr/local/bin/bazel, info, bazel-bin]
2021-06-16 11:57:55.050 [main] INFO    org.jetbrains.bsp.bazel.server.bazel.BazelRunner - Waiting for bazel - command: info, flags: [], arguments: [release]
2021-06-16 11:57:55.051 [main] INFO    org.jetbrains.bsp.bazel.server.bazel.BazelRunner - Running: [/usr/local/bin/bazel, info, release]

Any idea what may be happening here and why the server is never able to initialize? My example project is here and I'm not super familiar with Bazel, so I'm not ruling out that I did something wrong. However, with the 0.1.0 it does initialize with that build, so I'd assume it should with the latest dev as well. Any insight would be appreciated.

On a related note, since there does seem to have been a lot of changes since 0.1.0, is there any plans for another release soon?

SemanticDB Generation (gives find references)

from TODO list

Further reorganisation and breaking down of BazelBspServerBuildManager and BuildServerService

Suggested by @andrefmrocha
#24 (comment)
#24 (comment)
#24 (comment)

Implement buildTarget/scalaMainClasses

Possibility to grab diagnostic position instead of build target identifier position?

Wasn't sure how to exactly phrase the issue title, but I noticed given a really small example like:

package example

object Main extends App {
  val msg: Int = "Let's try to get Bazel BSP working with Metals" // <- line 3

  println(msg)
}

I'd sort of expect that the build/publishDiagnostics would lead the user to the type mismatch on line 3 so that they are able to quickly make the change and compile again. However, in the given scenario I notice that the diagnostic position that is returned is actually pointing to the BUILD file that defines the target.

[Trace - 01:43:04 PM] Received notification 'build/publishDiagnostics'
Params: {
  "textDocument": {
    "uri": "file:///Users/ckipp/Documents/scala-workspace/metals_bazel_tester/src/example/BUILD"
  },
  "buildTarget": {
    "uri": ""
  },
  "diagnostics": [
    {
      "range": {
        "start": {
          "line": 4,
          "character": 13
        },
        "end": {
          "line": 4,
          "character": 13
        }
      },
      "severity": 1,
      "message": "ERROR: /Users/ckipp/Documents/scala-workspace/metals_bazel_tester/src/example/BUILD:4:13: scala //src/example:Example failed: (Exit 1): scalac failed: error executing command bazel-out/darwin-opt-exec-2B5CBBC6/bin/external/io_bazel_rules_scala/src/java/io/bazel/rulesscala/scalac/scalac @bazel-out/darwin-fastbuild/bin/src/example/Example.jar-0.params"
    }
  ],
  "reset": false
}

This happens both in Metals:

And also in IntelliJ:

The actual diagnostic position that a user is probably more interested in is burried in there build/logMessage:

[Trace - 01:43:05 PM] Received notification 'build/logMessage'
Params: {
  "type": 4,
  "message": "ERROR: /Users/ckipp/Documents/scala-workspace/metals_bazel_tester/src/example/BUILD:4:13: scala //src/example:Example failed: (Exit 1): scalac failed: error executing command bazel-out/darwin-opt-exec-2B5CBBC6/bin/external/io_bazel_rules_scala/src/java/io/bazel/rulesscala/scalac/scalac @bazel-out/darwin-fastbuild/bin/src/example/Example.jar-0.params\nsrc/example/Main.scala:4: error: type mismatch;\n found   : String(\"Let\\\u0027s try to get Bazel BSP working with Metals\")\n required: Int\n  val msg: Int \u003d \"Let\u0027s try to get Bazel BSP working with Metals\"\n                 ^\none error found\nBuild failed\njava.lang.RuntimeException: Build failed\n\tat io.bazel.rulesscala.scalac.ScalacWorker.compileScalaSources(ScalacWorker.java:280)\n\tat io.bazel.rulesscala.scalac.ScalacWorker.work(ScalacWorker.java:63)\n\tat io.bazel.rulesscala.worker.Worker.persistentWorkerMain(Worker.java:92)\n\tat io.bazel.rulesscala.worker.Worker.workerMain(Worker.java:46)\n\tat io.bazel.rulesscala.scalac.ScalacWorker.main(ScalacWorker.java:26)\nTarget //src/example:Example failed to build\nUse --verbose_failures to see the command lines of failed build steps.\nINFO: Elapsed time: 0.220s, Critical Path: 0.09s\nINFO: 2 processes: 2 internal.\nFAILED: Build did NOT complete successfully"
}

Again, not super familiar with Bazel yet and still learning how everything is working, but I'm curious if there is a better way to tie into these diagnostics to instead return the diagnostic position in the source file rather than the BUILD file. I'd love to hear your thoughts.

bazelbuild/examples indexing problem

Scenario:

Import java-tutorial from https://github.com/bazelbuild/examples
Open Greeting.java

Observed:
Greeting.java is not correctly indexed - package name is marked as incorrect

Old Installer command line arguments should be moved to the ProjectView

Recently we introduced ProjectView, which currently allows specifying project's targets and directories. Installer arguments does the same, but also allows changing path to java and bazel and it would be nice to move this configuration to the ProjectView as well.

Installer.java also needs some love`

things to do:

update Project View -- deprecated installer flags | #143
1.1.1 release with deprecated flags
update Installer.java -- the only argument should be path to project view, breaking change, so version 2.0.0

Intellij tests running fix

Now, green triangles in Intellij don't run tests properly via BSP - probably client-sided problem.

Bazel import stays idle dependencySources request

The current development version of bazel bsp has currently an issue where importing stays idle forever (or at least for the maximum given time that a request can take). This happens when it is attending to the buildTarget/dependencySources.

Native Kotlin Support

In order to proper support all of the features of rules_kotlin, there is a need for native Kotlin support over the BSP. After an extension of the protocol for kotlin has been built, it should be supported, especially in order to support KotlinJS modules.

Further bazel builder improvements

Bazel builder could be improved - specific building methods for query, run, build... Additional builders for query params and similar.

real configuration & constants

Configuration should be done properly - yaml or something similar, only needed fields. Rest of constants should be split somehow to reflect their sense .

(commons module update + tests)

Obtain used jdk

Currently, there is not jdk information being outputted regarding a build target since we weren't able to figure out how to query for this information yet.

Installer does not print the installation location

When you run java -cp "$bsp_path" org.jetbrains.bsp.bazel.install.Install the installer prints Bazel BSP server installed in, but there is no location provided

Parameterize `workspace/buildTargets` to import a subset of the workspace

Whilst there isn't better client support for importing a subset a project, this parameterisation could be allowed during the installation of the server.

Tests for ActionGraphParser

All ActionGraphParser implementations need more tests

java_library exports are not passed to the client

I think that

java_library(
    [...]
    exports = [
        "//some/target",
    ],
    [...]
)

is not properly resolved. The workspaceBuildTargets response does not contain any deps, what probably causes that a client cannot see some classes and methods occurrences.

server assumes only scala_test targets - more flexibility needed

ScalaBuildServerService assumes only scala_test targets. Rules Scala has support for scala junit tests and Specs2 support is added via that rule: https://github.com/bazelbuild/rules_scala/blob/master/scala/scala.bzl#L38 - we need to support it as well

things to do:

EASY - include such targets in the BSP project
HARD - include test classes in the BSP - we need to figure out how to obtain such information from test discovery mechanism

jetbrains / bazel-bsp Goto Github PK

bazel-bsp's Introduction

Bazel BSP

Supported languages

Installation

Easy way (coursier)

More difficult way (from sources)

Using install script

Using coursier

Project Views

Tests

Unit tests

End-to-end tests

Contributing

bazel-bsp's People

Contributors

Stargazers

Watchers

Forkers

bazel-bsp's Issues

solution should be quite easy - update validation regex, but are there any other correct version formats not considered?

Recommend Projects

Recommend Topics

Recommend Org