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

New Sync View #6813

Merged
merged 19 commits into from
Oct 18, 2024
Merged

New Sync View #6813

merged 19 commits into from
Oct 18, 2024

Conversation

LeFrosch
Copy link
Collaborator

@LeFrosch LeFrosch commented Sep 30, 2024

Adds the option to use the platform sync view instead of the bazel custom one. Errors are also collected using BEP in the new view to improve the quality of reported issues.

Registry key: bazel.new.sync.view

Uses the platform sync view to display progress. However, progress no longer follows a tree structure.
Screenshot from 2024-10-02 10-54-03

The platform sync view offers sufficient space for BEP's detailed error messages.
Screenshot from 2024-10-02 10-54-16

@LeFrosch LeFrosch force-pushed the updated-sync-view branch 3 times, most recently from 7732e35 to 2072ae8 Compare October 2, 2024 08:59
@LeFrosch
Copy link
Collaborator Author

LeFrosch commented Oct 2, 2024

Rebased master

@LeFrosch LeFrosch force-pushed the updated-sync-view branch 4 times, most recently from 1717140 to 74f63c4 Compare October 7, 2024 13:44
@LeFrosch LeFrosch marked this pull request as ready for review October 7, 2024 14:00
@github-actions github-actions bot added product: CLion CLion plugin product: IntelliJ IntelliJ plugin product: GoLand GoLand plugin awaiting-review Awaiting review from Bazel team on PRs labels Oct 7, 2024
@mai93
Copy link
Collaborator

mai93 commented Oct 7, 2024

why is this better than the existing way? is the plan to make it the default?

@LeFrosch
Copy link
Collaborator Author

LeFrosch commented Oct 8, 2024

@mai93 The Idea was to show error messages received by BEP rather than parsing the command line output to increase the quality and relevance of reported errors. In my option, the sync and build view provided by the platform was better suited for displaying these longer messages. Furthermore, I hope that using the platform sync view can save us some maintenance work in the long run, since it is maintained by the platform team.

With regard to making this view the default, this depends, of course, on the feedback we receive. If it is well perceived, I see no reason for not doing so. But maybe it makes sense to make it opt-in in the beginning.

@mai93
Copy link
Collaborator

mai93 commented Oct 8, 2024

Thanks for the explanation! I'd propose guarding it with an experiment instead and enabling it incrementally because we have a lot of features added for specific users behind a key and we never got a sense if they are ready for general rollout.

@tpasternak
Copy link
Collaborator

Btw please hold on, does it work with query sync?

@LeFrosch
Copy link
Collaborator Author

LeFrosch commented Oct 9, 2024

@tpasternak I am not sure how the sync UI for query sync works but the new sync view is just a scope that can be added to the BlazeContext and processes IssueOutputs. If the view works well for regular sync I was planning to also adopt it for running builds and maybe we can also use it for query sync.

@tpasternak
Copy link
Collaborator

Ok, you can just add use_query_sync: true to the projectview file to test

import com.intellij.openapi.progress.TaskInfo
import com.intellij.openapi.wm.ex.ProgressIndicatorEx

object ProgressIndicatorStub : ProgressIndicatorEx {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we use EmptyProgressIndicator instead of this one?


object BuildViewMigration {
@JvmStatic
val enabled get(): Boolean = Registry.`is`("bazel.new.sync.view")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  val enabled 
    get(): Boolean = Registry.`is`("bazel.new.sync.view")

.submitTask(
indicator ->
Scope.root(
context -> {
if (Registry.is("bazel.new.sync.view")) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's use com.google.idea.blaze.base.buildview.BuildViewMigration#getEnabled here

import com.intellij.openapi.diagnostic.Logger
import com.intellij.openapi.extensions.ExtensionPointName

internal val LOG = Logger.getInstance(BuildEventParser::class.java)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

internal val LOG = logger<BuildEventParser>()

val exitCode = execute(ctx, cmdBuilder.build())
val result = BuildResult.fromExitCode(exitCode)

parseJob.cancelAndJoin()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this would cancel all the parsing because it can trigger a CancellationException from parseEvent

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I understand this can only trigger a CancellationException in parseEvent if parseEvent is waiting for more data. And in this case we actually want to cancel parseEvent because there is not going to be more data after the bazel process finished. The actual parsing cannot be cancelled as far as I can tell.

name: String = "BazelContext",
block: suspend CoroutineScope.() -> T,
): T {
val deferred = scope.async(Dispatchers.IO + CoroutineName(name)) { block() }
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no need in IO use right here

var newScope = new ToolWindowScope.Builder(project, task)
.setProgressIndicator(indicator)
.setPopupBehavior(BlazeUserSettings.FocusBehavior.ON_ERROR)
.setIssueParsers(targetDetectionQueryParsers(project, WorkspaceRoot.fromProject(project)))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you please double check this line should be removed?

@LeFrosch LeFrosch force-pushed the updated-sync-view branch 3 times, most recently from 51586a2 to eec4260 Compare October 15, 2024 07:53
Copy link
Collaborator

@ujohnny ujohnny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good, let's add got it promotion as a separate PR

@LeFrosch LeFrosch merged commit c1a3c5a into bazelbuild:master Oct 18, 2024
6 checks passed
@LeFrosch LeFrosch deleted the updated-sync-view branch October 18, 2024 09:48
@github-actions github-actions bot removed the awaiting-review Awaiting review from Bazel team on PRs label Oct 18, 2024
@SergejSalnikov
Copy link

SergejSalnikov commented Nov 14, 2024

LeFrosch, could you please explain how to use the now final BuildResultHelper class with the remote builds? Yes, the BuildInvoker.createBuildResultHelper() method can be overridden, but it only can return an instance of final BuildResultHelper class that is cannot be customized.

@LeFrosch
Copy link
Collaborator Author

@SergejSalnikov If I remember correctly I just inlined the only implementation of the BuildResultHelper. I figured that the other implementation must have been google internal. Are you maintaining a fork?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
product: CLion CLion plugin product: GoLand GoLand plugin product: IntelliJ IntelliJ plugin
Projects
Development

Successfully merging this pull request may close these issues.

5 participants