Fabian Meumertzheim

@jonathanmetzman Is `/work` available in `build.sh`? I got an error when I tried to also unpack Maven into `/work` and then use it from the build script.

@jonathanmetzman This is what I'm seeing: Maven is unpacked correctly to `$WORK` in https://github.com/google/oss-fuzz/runs/4557838834?check_suite_focus=true#step:8:177, but then isn't found in https://github.com/google/oss-fuzz/runs/4557838834?check_suite_focus=true#step:8:261. This does work if I replace `$WORK` with `$SRC`, which...

This would be very useful. Just let me add that `testing.TestEnvironment` is simply a wrapper function around [`RunEnvironmentInfo`](https://bazel.build/rules/lib/RunEnvironmentInfo), which is the actual provider. If anyone wants to pick this up,...

Yes, other than `testing.TestEnvironment`, it's a regular Starlark-accessible provider available in Bazel 5.3.0.

@UebelAndre I'll be busy next week, but feel free to ping me the week after and I can give you some pointers and/or pair.

Yes, resolving it is required to allow for generic transition wrappers around tests, which is something I'm interested in.

I think I could work on it, but we should first figure out how we want the new `arguments` field on `RunEnvironmentInfo` (the replacement for the deprecated `testing.TestEnvironment`) to behave...

Yes, this is only about `run` and `test`. Implicitly passing arguments or environment variables to actions seems intrusive, but of course rulesets would be free to use the fields provided...

@lberki Is this also something you feel comfortable reviewing? I'm looking into `BAZEL_TRACK_SOURCE_DIRECTORIES` because I would personally like to see it flipped, maybe even for Bazel 6. It has seen...

@haxorz This is definitely unexpected. Could you elaborate a bit more on why you are planning to do this? As far as I understand the situation, having proper source directory...