chore: make integration test infrastructure sane

[chanseokoh]

The you-can-do-anything-in-bazel mentality can easily lure one to a state where you are programming a build with a build tool instead of configuring a build.

I just extracted the shell script portion out of a .bzl file into a file.

This should also help switching to any build system from Bazel.

[chanseokoh]

The script is taken out of integration_test.bzl above.

[codecov]

Codecov Report

Merging #904 (36f0382) into main (bfb35cd) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #904   +/-   ##
=======================================
  Coverage   87.86%   87.86%           
=======================================
  Files         153      153           
  Lines       16024    16024           
  Branches     1166     1166           
=======================================
  Hits        14079    14079           
  Misses       1602     1602           
  Partials      343      343           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bfb35cd...36f0382. Read the comment docs.

[chanseokoh]

Hmm... I will look into the failures on GitHub.

[chanseokoh]

Good to go.

[vam-google]

@chanseokoh Please consider reverting this PR as a whole or heavily refactoring it to eliminate the issues.

The issues are:

1. Before the generated code had also been compiled by bazel before going to golden files diff check, now compilation is not happening anymore. This is a big difference. This is so, because the integration_test rules were consuming gapic target directly (which produces a compiled java binary), and was getting the sources from it, which were guaranteed to be already compiled and formatted properly. Now the build depends on srcjar_raw intermediate artifact, which gets created before compilation, and since the subsequent compilation is not needed for the final test target to execute, bazel will truncate in from build execution tree as redundant.

2. The build file now directly references the implementation-specific aspects of the rules (the names of intermediate build artifacts, which srcjar_raw is): https://github.com/googleapis/gapic-generator-java/pull/904/files#diff-d0ca181e8f4c33142243bd935d28e96c7fb6d1c3f99dbedb386f209c0f3f52a5R53. Like an oversimplified analogy to this would be accessing private variable form another class directly instead of having a getter method. Basically here bazel gets used as a script-calling tool (a severely complicated one), instead of using it as a rigorous powerful build system.

[chanseokoh]

We have offline discussions.

FTR,

now compilation is not happening anymore. This is a big difference.

Turns out this wasn't the case (although it could have been), and therefore there's no difference after this PR.

If it is required to verify if generated libraries are compilable, we should do that. It can be done by adding tests to CI. And in fact, we already have such tests (recently added).

Basically here bazel gets used as a script-calling tool (a severely complicated one)

Bazel was used as a tool to call many severely complicated scripts (embedded ones) anyway. However, one could argue that the complexity is hidden as an implementation detail, where the following argument is in the same vein.

Like an oversimplified analogy to this would be accessing private variable form another class directly instead of having a getter method

I have arguments about this, but here, I'd just leave here that we don't see this as an issue. In fact, I think we are making this better by doing this.