Skip to content
This repository was archived by the owner on Sep 30, 2024. It is now read-only.

SG start bazel enhancements #59718

Merged
merged 23 commits into from
Feb 6, 2024
Merged

SG start bazel enhancements #59718

merged 23 commits into from
Feb 6, 2024

Conversation

jamesmcnamara
Copy link
Contributor

@jamesmcnamara jamesmcnamara commented Jan 19, 2024

Just getting this up in a draft status so it can get some eyes on it. There are a lot of changes and still some known bugs that I need to resolve but its close.

High Level Changes

  • Unified BazelCommands and Commands under one interface SGConfigCommand
  • Split runAndWatch into many different pieces
  • Added an Installer interface to capture events that can be installed
  • Brought together all uses of startedCmd by using a commandOptions struct

I'll call out more inline

Known Issues

  • iBazel output is suppressed after installation so errors are invisible. I need some sort of channel signal to start piping output after installation is complete (can't be before because it breaks the progress bars)
  • iBazel go routines are not properly managed/awaited
  • bazel targets take a long time to start up (unknown why)

Test plan

Manually tested locally

@cla-bot cla-bot bot added the cla-signed label Jan 19, 2024
Comment on lines +1 to +17
[
{
"regex": "^Check that imports in Go sources match importpath attributes in deps.$",
"command": "./dev/bazel_configure_accept_changes.sh",
"args": []
},
{
"regex": "missing input file",
"command": "./dev/bazel_configure_accept_changes.sh",
"args": []
},
{
"regex": ": undefined:",
"command": "./dev/bazel_configure_accept_changes.sh",
"args": []
}
]
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Contains patterns of bazel output and the command to run to try to auto fix it. iBazel will use this to to try to auto-resolve build problems.

@jamesmcnamara jamesmcnamara requested a review from a team January 19, 2024 04:58
Copy link
Contributor

@jhchabran jhchabran left a comment

Choose a reason for hiding this comment

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

only did a cursory review, will come back to this to follow properly the execution cinematic :)

lots of nits, don't pay attention too much to them

#! /bin/bash

# Run bazel configure and if the error code is 110, exit with error code 0
# This is because 110 means that configuration files were successfully
Copy link
Contributor

Choose a reason for hiding this comment

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

looks like the sentence is cut over here :D


secretsEnv, err := getSecrets(ctx, bc.Name, bc.ExternalSecrets)
func (bc BazelCommand) watchPaths() ([]string, error) {
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: shouldn't this be watchedPaths? I intuitively read watchPaths as "I will watch those paths" not as "get me the paths that I should watch"

if bc.IgnoreStderr {
std.Out.WriteLine(output.Styledf(output.StyleSuggestion, "Ignoring stderr of %s", bc.Name))
stderrWriter = sc.stderrBuf
func (bc BazelCommand) StartWatch(ctx context.Context) (<-chan struct{}, error) {
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: Watch(ctx context.Context) ... ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Would love to but but both Command and BazelCommand use Watch for a local field.

}

func (cmd Command) watchPaths() ([]string, error) {
root, err := root.RepositoryRoot()
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: we're doing this over and over for every command, it's most likely harmless to run it each time, but we could do this at construction time, when we're building commands.

sc.cancel = cancel
ctx, cancel := context.WithCancel(ctx)
sc.cancel = func() {
sc.Cmd.Process.Signal(os.Interrupt)
Copy link
Contributor

Choose a reason for hiding this comment

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

As per the godoc in exec.Cmd

	// If Cancel is non-nil, the command must have been created with
	// CommandContext and Cancel will be called when the command's
	// Context is done. By default, CommandContext sets Cancel to
	// call the Kill method on the command's Process.
	// If the child process has failed to exit — perhaps because it ignored or
	// failed to receive a shutdown signal from a Cancel function, or because no
	// Cancel function was set — then it will be terminated using os.Process.Kill.

Therefore, I think we don't need to handle this explicitly, did this result of observing a different behaviour when you tested the implementation?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes I saw a ton of orphan child processes but there were lots of other bugs that have been resolved since then. Maybe this can be removed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah I am definitely still seeing this problem. I think the issue is exactly that it's using SIGKILL which doesn't do any cleanup, which specifically orphans any child processes. So for example docsite and web both spin up servers in child processes and then you get EADDRINUSE all over the place.

Adding a proper interrupt fixed it for me.

stderrWriter = io.MultiWriter(logger, sc.stderrBuf)
eg, err := process.PipeOutputUnbuffered(ctx, sc.Cmd, stdoutWriter, stderrWriter)
func profileEventsFilePath(eventsDir string) string {
return path.Join(eventsDir, "profile.json")
Copy link
Contributor

Choose a reason for hiding this comment

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

IIRC this can be overriden by a command line flag, shouldn't we perhaps always explicitly set this when calling iBazel so we're 100% sure it'll be there?

"Might as well check Slack. %s is taking its time...",
"In German there's a saying: ein guter Käse braucht seine Zeit - a good cheese needs its time. Maybe %s is cheese?",
"If %ss turns out to be cheese I'm gonna lose it. Hey, hurry up, will ya",
"Still waiting for %s to finish installing...",
Copy link
Contributor

Choose a reason for hiding this comment

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

We should make a tradition for anyone editing this file to add a new one :D

@jamesmcnamara jamesmcnamara marked this pull request as ready for review January 23, 2024 18:58
Copy link
Contributor

@jhchabran jhchabran left a comment

Choose a reason for hiding this comment

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

@jamesmcnamara I don't want to block you further and as long as we don't replace the default target, this isn't going to break anything, so I'm inclined to LGTM :)

@jamesmcnamara jamesmcnamara merged commit 00185f9 into main Feb 6, 2024
@jamesmcnamara jamesmcnamara deleted the jsm/sg-start-bazel branch February 6, 2024 04:30
eseliger added a commit that referenced this pull request Feb 9, 2024
eseliger added a commit that referenced this pull request Feb 9, 2024
…60362)

* Revert "Made all file watches in `sg start` recursive (#60285)"

This reverts commit 4b8a403.

* Revert "SG start bazel enhancements (#59718)"

This reverts commit 00185f9.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants