Top-post comment: Aggregation of test results is hard. We've had a million
threads on it. You want to have a clear green "this runner works" signal
but you also want completely isolated "this runner works for Java" / "this
runner works for Python" / etc signals. The tension between these is
Conversely, by unifying to Gradle command names, it also teaches how folks
can run these things locally.
Doesn't help entirely with discoverability, or initial scrutability, but it
feels lower impedance than someone needing to look at the action manually
to learn what it's running under the hood
> Just to clarify: I'm not proposing tying them to gradle tasks (I'm fine
with `go test` for example) or doing this in situations where it is
unnatural.
> My example probably confused this because I left off the `./gradlew` just
to save space. I'm proposing naming them after their obvious repro
+1 to the general proposal.
I'm not bothered if something says a gradle command and in execution, that
task ends up running multiple different commands. Arguably, if we're
running a gradle task manualy to prepare for a subsequent task that latter
task should be adding the former to it's
On Tue, Oct 10, 2023 at 10:21 AM Danny McCormick via dev <
dev@beam.apache.org> wrote:
> I'm +1 on:
> - standardizing our naming
> - making job names match their commands exactly (though I'd still like the
> `Run` prefix so that you can do things like say "Suite XYZ failed" without
> triggering
I'm +1 on:
- standardizing our naming
- making job names match their commands exactly (though I'd still like the
`Run` prefix so that you can do things like say "Suite XYZ failed" without
triggering the automation)
- removing pre/postcommit from the naming (we actually already run many
precommits
Thanks for raising this. This generally works, though some jobs run more
than one gradle task (e.g. some IO_Direct_PreCommit run both :build (which
executes unit tests) and :integrationTest).
Another option is to normalize the naming of every job, saying the job name
is X, then workflow name is
I'm +1 on standardizing the names and while I don't have a strong opinion
on which standard (so long as it's only one) using the Gradle name seems
like a perfectly good choice... I don't know the GHA setup well enough, but
would that help maintain those? Presumably the various actions all
FWIW I aware of the README in
https://github.com/apache/beam/tree/master/.test-infra/jenkins that lists
the phrases alongside the jobs. This is just wasted work to maintain IMO.
Kenn
On Tue, Oct 10, 2023 at 9:46 AM Kenneth Knowles wrote:
> *Proposal:* make all the job names exactly match the
