search

buildbarn / bb-deployments

Example deployments of Buildbarn on various platforms
Apache License 2.0
102 stars 70 forks source link

Upgrade to latest Buildbarn 2022-04 #66

Closed moroten closed 2 years ago

moroten commented 2 years ago

With the dummy_for_dependencies.go file, 'go mod tidy' will generate the go.mod and go.sum files with the dependencies that otherwise are only specified in BUILD.bazel files. This means that Gazelle will also add them to go_dependencies.bzl.

To update the dependency files, run: $ go mod tidy $ bazel run //:gazelle -- update-repos -from_file=go.mod -to_macro go_dependencies.bzl%go_dependencies -prune Then format go_dependencies.bzl using $ sed -i '/^$/d' go_dependencies.bzl $ bazelisk run @com_github_bazelbuild_buildtools//:buildifier

moroten commented 2 years ago

Currently, I'm getting Runner ... is not ready: rpc error: code = Unknown desc = Failed to create client connection: failed to build resolver: invalid (non-empty) authority: .. Doesn't gRPC support relative paths to the unix sockets? Adding std.extVar('PWD') results in Error while dialing dial unix /home/fredrik/.cache/bazel/_bazel_fredrik/.../bare.runfiles/com_github_buildbarn_bb_deployments/runner: connect: invalid argument". I'm considering to change to TCP instead unless anyone knows the solution.

I will also add a fake Go project to get go mod tidy etc. work out of the box.

I haven't touched kubernetes/ yet.

EdSchouten commented 2 years ago

gRPC clients need to use address: 'unix:///some/path'. I think it may be relative if you use double slashes instead of triple, but you do need to prefix it with unix://.

lyml commented 2 years ago

@EdSchouten according to https://github.com/grpc/grpc/blob/master/doc/naming.md it is unix:<relative path> or unix://<absolute path>

I've updated it and it runs smoothly bare and with docker-compose however with kubernetes on minikube the runner is getting a Code 2: Failed to run command: Failed to open stdout path "67271f46899f7971/stdout": permission denied. I have no idea how this permission issue could show up only for the kubernetes since it's mostly identical to the docker-compose configuration it might just be my local minikube which is a bit forked up.

EdSchouten commented 2 years ago

I've updated it and it runs smoothly bare and with docker-compose however with kubernetes on minikube the runner is getting a Code 2: Failed to run command: Failed to open stdout path "67271f46899f7971/stdout": permission denied. I have no idea how this permission issue could show up only for the kubernetes since it's mostly identical to the docker-compose configuration it might just be my local minikube which is a bit forked up.

I think you may need to add this to the bb_worker config:

global: { setUmask: { umask: 0 } }

The umask used to be set to zero in the past, but this is no longer done by default, as it isn't always desirable. That should fix the permissions issue.

moroten commented 2 years ago 
global: { setUmask: { umask: 0 } }

The umask used to be set to zero in the past, but this is no longer done by default, as it isn't always desirable. That should fix the permissions issue.

That did sort the Kubernetes config!

We haven't removed rbe_autoconfig. That has to be a separate job. At least all configs have become up to date.