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

Feature/freshen up windows workers #126

Merged

Conversation

stagnation
Copy link

@stagnation stagnation commented Feb 8, 2024

.

@stagnation stagnation marked this pull request as draft February 8, 2024 09:16
@stagnation stagnation force-pushed the feature/freshen-up-windows-workers branch 3 times, most recently from e0d5056 to 5ae118c Compare July 10, 2024 08:42
@stagnation stagnation marked this pull request as ready for review July 10, 2024 08:51
Comment on lines 130 to 133
func (be *localBuildExecutor) Execute(ctx context.Context, filePool re_filesystem.FilePool, monitor access.UnreadDirectoryMonitor, digestFunction digest.Function, request *remoteworker.DesiredState_Executing, executionStateUpdates chan<- *remoteworker.CurrentState_Executing) *remoteexecution.ExecuteResponse {
func (be *localBuildExecutor) Execute(ctx context.Context, filePool re_filesystem.FilePool, monitor access.UnreadDirectoryMonitor, digestFunction digest.Function, request *remoteworker.DesiredState_Executing, executionStateUpdates chan<- *remoteworker.CurrentState_Executing) (response *remoteexecution.ExecuteResponse) {
// Timeout handling.
response := NewDefaultExecuteResponse(request)
response = NewDefaultExecuteResponse(request)
Copy link
Member

Choose a reason for hiding this comment

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

Why is this change needed? If it's not needed, please revert.

Copy link
Author

Choose a reason for hiding this comment

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

No it is not needed 👍. I assumed when first trying to modify the response in the defer closure that we needed to have the name captured as a named output. Then forgot it when I rewrote the code to just log, and now that we send the error again I find that this change is not needed.

Comment on lines 164 to 170
defer func() {
err := buildDirectory.Close()
if err != nil {
log.Printf("Failed to clean up build environment: %v\n", err)
}
}()
Copy link
Member

Choose a reason for hiding this comment

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

Can't we simply do:

defer func() {
    if err := buildDirectory.Close(); err != nil {
        attachErrorToExecuteResponse(response, util.StatusWrap(err, "Failed to close build directory"))
    }
}()

?

Copy link
Author

Choose a reason for hiding this comment

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

Yes. I have a commit to do just that, and am looking into a better way to avoid Bazel retrying and printing follow up errors to the user.

This is the commit message if you find it useful, or I can prune it if it is too much information.

    Send failure to clean up build directory to the client

    The client may choose to retry the action and then receive a different
    follow-up error.

        Action: http://.../remote-execution/blobs/sha256/action/6068c5370fdcca9dfb70936f5ea481cf53092c5c3ea328e351a69641d5c7fbfa-169/
        ExecuteResponse: {...,
            "status":{
                "code":13,
                "message":"Failed to close build directory: Failed to remove build directory \"6068c5370fdcca9d\": Failed to remove \"root/external/com_google_absl/absl/base/internal\": directory not empty"
            }}

        Action: http://.../remote-execution/blobs/sha256/action/6068c5370fdcca9dfb70936f5ea481cf53092c5c3ea328e351a69641d5c7fbfa-169/
        ExecuteResponse: {...,
            "status":{
                "code":13,
                "message":"Failed to acquire build environment: Failed to create build directory \"6068c5370fdcca9d\": Cannot create a file when that file already exists."
        }}

Copy link
Author

Choose a reason for hiding this comment

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

Concurrency is also an important note here if we want to accurately describe the current state of affairs, or we can punt that and look at the required improvements instead.

@@ -25,6 +26,24 @@ func NewPlainCommandCreator(sysProcAttr *syscall.SysProcAttr) CommandCreator {
return func(ctx context.Context, arguments []string, inputRootDirectory *path.Builder, workingDirectoryParser path.Parser, pathVariable string) (*exec.Cmd, error) {
Copy link
Member

Choose a reason for hiding this comment

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

If we can't get rid of this CommandCreator implementation, can we at least ensure it's as similar to the one we use on UNIX as possible, in terms of comments, ordering of statements, etc. etc. etc.

Copy link
Author

Choose a reason for hiding this comment

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

Yepp!

return nil, err
}

arguments[0] = "\\nonexistent-place-back-later"
Copy link
Member

Choose a reason for hiding this comment

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

This is mutating one of the input arguments of this function. Is this safe/desirable? Considering that we call exec.CommandContext() with arguments[0] and arguments[1:] separately, why not just pass in the string there?

Copy link
Author

Choose a reason for hiding this comment

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

Yes. With the shared command creator that is much better. This was an artifact from also setting the argv0 on Windows to match cmd.Path. But It could have been implemented better. Now though we do not choose to do so.

pkg/runner/local_runner_windows.go Outdated Show resolved Hide resolved
@stagnation stagnation force-pushed the feature/freshen-up-windows-workers branch 2 times, most recently from 36aefe2 to e44ccf7 Compare July 15, 2024 13:16
@@ -2,6 +2,7 @@ package builder

import (
"context"
"log"
Copy link
Member

Choose a reason for hiding this comment

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

I think this should be removed.

@@ -160,7 +161,14 @@ func (be *localBuildExecutor) Execute(ctx context.Context, filePool re_filesyste
util.StatusWrap(err, "Failed to acquire build environment"))
return response
}
defer buildDirectory.Close()
defer func() {
err := buildDirectory.Close()
Copy link
Member

Choose a reason for hiding this comment

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

if err := buildDirectory.Close(); err != nil {

Nils Wireklint added 2 commits July 15, 2024 15:23
The client may choose to retry the action and then receive a different
follow-up error.

    Action: http://.../remote-execution/blobs/sha256/action/6068c5370fdcca9dfb70936f5ea481cf53092c5c3ea328e351a69641d5c7fbfa-169/
    ExecuteResponse: {...,
        "status":{
            "code":13,
            "message":"Failed to close build directory: Failed to remove build directory \"6068c5370fdcca9d\": Failed to remove \"root/external/com_google_absl/absl/base/internal\": directory not empty"
        }}

    Action: http://.../remote-execution/blobs/sha256/action/6068c5370fdcca9dfb70936f5ea481cf53092c5c3ea328e351a69641d5c7fbfa-169/
    ExecuteResponse: {...,
        "status":{
            "code":13,
            "message":"Failed to acquire build environment: Failed to create build directory \"6068c5370fdcca9d\": Cannot create a file when that file already exists."
    }}
@stagnation stagnation force-pushed the feature/freshen-up-windows-workers branch from e44ccf7 to 3ab02e3 Compare July 15, 2024 13:23
@EdSchouten EdSchouten merged commit 9850e82 into buildbarn:master Jul 16, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants