Obsolete
Status Update
Comments
ma...@gmail.com <ma...@gmail.com> #2
Bazel team sitting close to the Gerrit one in Google Munich.
ma...@gmail.com <ma...@gmail.com> #3
Possible to match Bazel's own event in November, Mountain View?
ma...@gmail.com <ma...@gmail.com> #4
ek...@google.com <ek...@google.com> #5
Asked David Ostrovsky for input on potential topics for a Bazel talk at a Gerrit user summit.
ma...@gmail.com <ma...@gmail.com> #6
[Empty comment from Monorail migration]
da...@gmail.com <da...@gmail.com> #7
As of July 2019, Gerrit build tool chain is very stable. The only issues that
we have to fix on regular base is Bazel CLI flags/Starlark features deprecation
and removal.
The stability window, feature deprecation policy and flipping the
discontinued flags were always a problem for us (and for projects we transitively
depend on, like rules_closure and protobuf).
In September 2019, Bazel version 1.0 is scheduled to be released: [1]
and I expect that it should be easier to maintain Gerrit build tool chain,
as Bazel CLI flags/Starlark features going to be much more stable.
Concerning the build toolchain itself, there are number of issues that could be
improved:
1. PolyGerrit build tool chain is pretty much outdated and it is *still* using
bower package manager, that is deprecated for years now: [2]. We should port
the PolyGerrit build tool chain to npm/yarn/rules_nodejs.
2. Caching of Bazel artifacts is based on local action cache feature, and thus
it depends on the content of the cached artifacts, created during the Docker Image
build for GerritForge CI. This is better than no caching at all, but obviously,
conceptually wrong, as the cached artifacts become outdated and thus getting
rebuild all the time. The way forward is new and shiny remote caching feature.
Needless to say that it is not trivial to switch to remote caching as we would need
a central build infrastructure and this would mean complete refactoring of the
current GerritForge CI set up.
Google Cloud platform announced Remote Build Execution for GCP alpha: [3] and
Han-Wen Nienhuys started to work on supporting RBE for Gerrit/GerritForge CI during
the last Hackathon but this work seems to be staled.
3. Support for new Java Language features for new JDK versions: JDK 11 and JDK 12.
Gerrit build tool chain should support building and running of Gerrit on the latest JDK
versions.
[1]https://github.com/bazelbuild/bazel/issues/8573
[2]https://github.com/bower/bower/issues/2298
[3]https://blog.bazel.build/2018/10/05/remote-build-execution.html
we have to fix on regular base is Bazel CLI flags/Starlark features deprecation
and removal.
The stability window, feature deprecation policy and flipping the
discontinued flags were always a problem for us (and for projects we transitively
depend on, like rules_closure and protobuf).
In September 2019, Bazel version 1.0 is scheduled to be released: [1]
and I expect that it should be easier to maintain Gerrit build tool chain,
as Bazel CLI flags/Starlark features going to be much more stable.
Concerning the build toolchain itself, there are number of issues that could be
improved:
1. PolyGerrit build tool chain is pretty much outdated and it is *still* using
bower package manager, that is deprecated for years now: [2]. We should port
the PolyGerrit build tool chain to npm/yarn/rules_nodejs.
2. Caching of Bazel artifacts is based on local action cache feature, and thus
it depends on the content of the cached artifacts, created during the Docker Image
build for GerritForge CI. This is better than no caching at all, but obviously,
conceptually wrong, as the cached artifacts become outdated and thus getting
rebuild all the time. The way forward is new and shiny remote caching feature.
Needless to say that it is not trivial to switch to remote caching as we would need
a central build infrastructure and this would mean complete refactoring of the
current GerritForge CI set up.
Google Cloud platform announced Remote Build Execution for GCP alpha: [3] and
Han-Wen Nienhuys started to work on supporting RBE for Gerrit/GerritForge CI during
the last Hackathon but this work seems to be staled.
3. Support for new Java Language features for new JDK versions: JDK 11 and JDK 12.
Gerrit build tool chain should support building and running of Gerrit on the latest JDK
versions.
[1]
[2]
[3]
ek...@google.com <ek...@google.com> #8
Thanks a lot for your input! I agree that these are important topics that we should address. Since this issue is about finding a topic for a possible Bazel talk at a Gerrit user summit, I've filed separates issue to keep track of these points:
-https://crbug.com/gerrit/11226 : PolyGerrit build tool chain is pretty much outdated
-https://crbug.com/gerrit/11227 : Consider making use of Bazels remote caching feature
-https://crbug.com/gerrit/11228 : Enable Gerrit to use JDK 11 and JDK 12
Offline I talked with David further about potential Bazel topics for a talk at a Gerrit user summit, but we found none. In the past David already did several Bazel talks and there was only little interest in them (e.g. there were almost no questions). Hence we think there is currently no demand for such a talk.
-
-
-
Offline I talked with David further about potential Bazel topics for a talk at a Gerrit user summit, but we found none. In the past David already did several Bazel talks and there was only little interest in them (e.g. there were almost no questions). Hence we think there is currently no demand for such a talk.
is...@google.com <is...@google.com> #9
Edits were made to reflect the following in Monorail: auto-CCs.
Description