+1, I think this is a good idea. The only downside I can think of is a
little bit of extra time per local build, but it seems like a worthwhile
tradeoff. 2 additional suggestions:
- we could consider doing this across languages as well (e.g. running the
python lint and format precommits as part of
+1 to anything we can do to automate this. I love having autoformat every
time I save in an IDE though I haven't set that up for Beam.
FWIW spotlessApply is fast enough that even autoformatting the whole
codebase is pretty much negligible time (and dominated by gradle reading
configs). I never bot
This is your daily summary of Beam's current high priority issues that may need
attention.
See https://beam.apache.org/contribute/issue-priorities for the meaning and
expectations around issue priorities.
Unassigned P1 Issues:
https://github.com/apache/beam/issues/33254 The PreCommit Java
Ideally, we would as much as possible eliminate the container as a part of
the contract a user expects. Hyrum's dead end is where progress is halted
or slowed because users have come to depend on things not intended. We have
not been very successful, but the intention has always been that the use o
I think the issue is independent of releasing since it is a CI thing. And I
think Yi is actually pointing out that it will be a user thing (since users
will want to use newer JDK also)
But still I agree that as the project matures the pro/con of making modules
more independent changes. So if that
Hi,
there is interesting thread in Maven dev list [1], which discusses
automatic spotlessApply as part of build. I personally use exactly same
approach on other projects - i.e. compileJava depends on spotlessApply.
The benefit is that CI rarely fails due to spotless (the only
possibility is a
