Job summary lists unwanted results for builds invoked by tooling and/or tests

[snazy]

We have CI workflows/jobs setup w/ the Gradle build action - it's running fine w/o any issues for quite a while now.

The only thing that I do not fully understand is that the build summary lists a lot of "phantom" Gradle builds that requested the classes task (see screenshot), although the workflow does not do that, neither do our build files directly.

We do use the Quarkus plugin in our builds, and I suspect that the Quarkus plugin somehow triggers/causes these "phantom" builds listed in the summary.

Would it be possible to hide these "phantom" builds in the action?

Workflow reference
"Heads-up" on the Quarkus side: quarkusio/quarkus#29890

[bigdaz]

The gradle-build-action adds an init-script to Gradle User Home that applies to all Gradle build invocations. This allows the action to capture details of all builds executed in a GitHub Actions workflow. This has the benefit of allowing users to configure a single "Setup Gradle" step in their workflow job and then have simple run actions to invoke Gradle.

The downside of this approach is that any Gradle invocation that uses the same Gradle User Home will have the init script applied, and the resulting builds will appear in the summary. This can include builds run as part of integration tests or by a tool like Quarkus.

I'll leave this issue open since we should make it possible/easier for these builds not to pollute the job summary.

[nnellanspdl]

I'm having this issue, but I think my problem is slightly different.

I'm one of the strange ones who uses long-lived github runners. Over time, these runners run many different gradle builds from many different projects.

It has gotten to the point now when I do a single gradle build of a single project, my build summary shows 100's of lines, showing various projects that are not related to my current build.

Is this something to do with cache, or possibly with a cluttered gradle user home? I've added a step at the beginning of my workflow that clears ~/.gradle but that doesn't seem to help.

[bigdaz]

@nnellanspdl Yes this likely has a different cause. Can you please open a separate issue to track this?