This provides an HTML-only PolyGerrit plugin consistent with our
Gitea theming, generously provided by Paladox (many thanks!).
Since we have to split some roles in the build playbook, also name
the temporary patching role to make the build console a little
easier to read.
Change-Id: I3baf17d04b2dca34fc23dcab91c00544cedf0ca6
Gerrit 3.2 supports java 11 now and Gerrit 3.3 will be the last to
support java 8. Lets get ahead of things and switch to java 11.
Change-Id: I1b2f6b1bdadad10917ef5c56ce77f7d7cfc8625d
The previous change built new images but didn't promote them because we
only modified the jobs. This change modifies the dockerfiel to ensure
the promote jobs also run.
Change-Id: I25722e64e7a36d396e217b9de14bd4b202ed95c8
Having upgraded to 3.2, we don't need these versions any more.
Change-Id: Ifc37a75aa62b2498e649a4c81b589a04c794184a
Depends-On: https://review.opendev.org/763617
This change modifies the Dockerfile to ensure the promote job runs.
It also updates the branches used to build against to pull recent
security updates which don't seem to hvae made it to the proper stable
branches yet.
Change-Id: I2cc9a67515ffdf256fccf5771cf4cf327ed9dbd5
We name the base image we build gerrit-base and we expose port 8081
not 8080 as opendev's gerrit listens on 8081.
Also explicitly build the javamelody plugin deps jar and copy it into
the review_site/lib dir on Gerrit 2 bazel builds. This is necessary
according to javamelody plugin build docs. In order to split Gerrit 2.x
and 3.x behavior in the Bazel builds we convert our Dockerfile into a
multi stage build.
All this ended up down a thread pull where the script in the Dockerfile
dir called build-gerrit.sh isn't actually used to build gerrit :/
clarify that. The script may be useful for local builds so we haven't
removed it yet.
Finally update gerrit plugin checkouts to tags or master as appropriate
where stable branches don't exist for the specified version.
Change-Id: I155a20685b3462e965c4216d134b3b36978fbcc7
base and builder are currently pinned to 3.7, which makes it hard
to consider upgrading to python-3.8. To help with that, make
python-3.7 and python-3.8 images, but point latest as 3.7 for the
time being. Then add version-specific provides and FROM lines
so that we can start being deliberate and clear about our version
choice.
Change-Id: Ibf1d846d5c4a005547785124567ce2900e272a7a
We disable these on our VM images, so might as well make our
container images follow suit. Could make them a smidge smaller.
Also do it in the gerrit-base image.
Change-Id: Iba60cf5c7009d57c4910f9e4464aff9231598ad6
We don't use the bazel image anymore, so it can go away.
Also, the bouncy castle line in the gerrit base dir is bong.
Change-Id: I58842dd9adee108893c0c953c4bb8361b9117775
We install jeepyb and launchpadlib in gerrit-base. Those are
important. We also need to add cgi for gitweb.
The gerrit init command does two things that we don't actually
want it to do at runtime. It extracts the plugins into the
plugins dir, and it downloads the right database library.
We can extract the plugins for it during image creation, and
then we can also download the plugin it would have downloaded.
We can also download the mysql library for it:
https://gerrit.googlesource.com/gerrit/+/refs/heads/stable-2.13/gerrit-pgm/src/main/resources/com/google/gerrit/pgm/init/libraries.config
Finally, we tell it to not download or expand anything during
init, because we're running in a container and next time we run
the process that dir isn't going to be there.
Our gerrit integration tests don't depend on our gerrit image builds.
Put in image depends between run-review and gerrit builds.
We also need to depend directly on opendev-buildset-registry.
Add java.security.egd setting to java invocation
This tells java to be secure.
https://stackoverflow.com/questions/58991966/what-java-security-egd-option-is-for
Add support for setting heap limit properly
The gerrit init script does this based on the value in
container.javaOptions. We could, but then we'd have to
run an entrypoint script. Instead, set the value via
the JAVA_OPTIONS env var setting based on a value from
ansible.
Finally, make gerrit-master image build non-voting
It looks like there might be a real issue, but debugging that
is not important for us at this moment.
Depends-On: https://review.opendev.org/714216
Change-Id: I01e94c10f470fb3c8ddfce7b0e201357e5050679
We need to use bazelisk to build gerrit so that we can properly
track bazel versions in the job. Use the roles developed for
gerrit-review to do that, then simplify the dockerfile to have
it simply copy the war into the target image.
Also add polymer-bridges.
Depends-On: https://review.opendev.org/709256
Change-Id: I7c13df51d3b8c117bcc9aab9caad59687471d622
To make it clear that docker hub is but one of many possible registries,
update our usage of FROM and image: lines to include docker.io in the
path.
There are a few other FROM lines for the gitea images which are handled
in a separate stack.
Change-Id: I6fafd5f659ad19de6951574afc9a6b6a4cf184df
Java is in /usr/local in these base images. Also, combining
ENTRYPOINT and CMD with [] syntax seems to lead to the whole
thing with [ getting passed to the entrypoint - which leads to
errors like:
/bin/sh: 1: [/usr/bin/java,: not found
Change-Id: I7c1ebdff58d6590724eaf5d429437a5c8c25fe22
Our existing config management puts files into hooks and static.
We can bind mount those in, but having the mount-points in the
image is useful.
The tmp dir is important for gerrit to be able to write
plugin expansions and javaamelody data.
Change-Id: Idd917c268ed7bdead412620dfe3ca842736b7463
We need jeepyb installed because the content of the gerrit hook scripts
we install is done via jeepyb commands. Use python-builder so that we
can just install the jeepyb wheel.
Should we maybe transition these hooks into being zuul jobs?
Depends-On: https://review.opendev.org/683146/
Change-Id: I8899885b05d1e9f48b3f354ca22b360b54d455a3
Use latest bazel
It seems 0.27 is now too old. This is what happens when I go on vacation
apparently.
Add in a hack to override the bazelversion. We'll remove this once
https://gerrit-review.googlesource.com/c/gerrit/+/237495 lands and
has been merged up.
Change-Id: Ib7a6d33ce8bf8498fd5cd09b25087dc09acb8df4
There is a bunch of duplication which needs to be redone almost never.
Split those into their own images so we can run them once and reuse them.
Change-Id: I923d4bff96dae75eb52a1c271fa52d5ae79933a0
We had some extra bazel options that don't seem to be necessary
anymore now that we are using upstream bazel options appropriately.
Retry the build a couple of times if it goes south, inside of the
build image. This should allow re-use of the cache the second time,
and if there is a temporary error, it should pick up and move
forward.
Change-Id: I5f304acb21fd3a4d40701fc0414ae0c424c838e5
During the Gerrit Hackathon, we learned some things about setting
bazel options. Use the ones recommended in upstream docs rather than
these. The outcome should be largely the same.
Change-Id: I32b4c567488f0739fb80f69dc881b9837803575c
Our goal is upgrading to 3.0. To do that we need to upgrade to 2.15, then
to 2.16, then to 3.0. Build all of the images so that we can do that.
2.16 and 3.0 also use bazel, so just use one copy of the Dockerfile for
all three and let zuul check out the repos to the right versions.
Depends-On: https://review.opendev.org/673147
Depends-On: https://review.opendev.org/672320
Change-Id: I35bd278e0c70c871fa44d005c60a987d1d8e3cdc
To provide a stepwise upgrade path from 2.13 running directly to
2.15 in a container, make a container image containing the war we're
using currently. This should let us make a change to how we run the
war without changing the war at all, and then update the war.
Instead of trying to make a clean build for gerrit 2.13 inside of a
builder image, just have it wget the already built wars and jars we
have.
There are pieces of this that duplicate what's being done in puppet,
but in this context it's not immediately clear these are important to
do. However, it's also not clear they're a bad idea.
The gerrit 2.15 build needs a newer bazel. Looking at the CI scripts
that are used by gerrithub, we find that they use bazel 0.26.1
and nodesource v10. Use the bazel image published by google to get
a bazel builder image.
Set gerrit uid/git to 3000 in both images to match the existing
directory ownership so that bindmounting doesn't face permissions
problems.
Change-Id: I3533f01c0859ed50640dcfd98023994c5867c056
Add jobs to build, upload, and promote a gerrit image to
Docker Hub. This uses alternative tags, build path, and
build args.
Change-Id: Iea7109f9ee0ec18431f298a2ecc611678a868d6d
Co-Authored-By: Monty Taylor <mordred@inaugust.com>
The gerrit source dir needs three plugins cloned into
the plugins dir and also a few files updated.
Depends-On: https://review.openstack.org/631007
Change-Id: I56037137d43ee1cea0a4c17e48d09102e1599ddc
