Julio Merino

OK, I _think_ I understand the bug now. 1. start calls waitExecution in a retrier loop. 2. waitExecution expects lastOperation to not be null, and it is not null on...

I pushed a new version of the change to (try to) fix the problems with the Windows tests... but now one of the Windows jobs fails with: ``` external\gazelle++go_deps+org_golang_x_sys\unix\vgetrandom_linux.go:7:9: file...

I have a POC of what I was looking for in https://github.com/bazelbuild/bazel/pull/21521

https://github.com/bazelbuild/bazel/pull/21559 contains a different take on the fix, which is simpler: just ignore classes that fail instrumentation and emit a warning for them.

@cushon Yes, we should be refactoring our code to avoid the large methods but it isn't that simple... One case is easy: we have a large parameters class with lots...

Inactivity doesn't mean the bug is gone.

Oh, if the process can be automated on GH Actions, for sure! I can incorporate this into the release pipeline and the next release will have an armv6 build :)

> lot of trial and error to get this working so I have around 20 commits on release.sh Yeah, that's the deal with CI workflow changes 😆 A PR tomorrow...

Hey Amitai, thanks for bringing this up. Not shipping a `Cargo.lock` is a mistake: best practices seem to dictate that one should ship a lock file for _binary_ crates, and...

Thanks for the PR, but it still doesn't resolve the issue for me. I'm now seeing NPEs: ``` FATAL: bazel crashed due to an internal error. Printing stack trace: java.lang.RuntimeException:...