Dear all,Debian jessie is no longer supported [1]. For us that means, that the current build slave containers for the Gerrit CI cannot be built anymore. I am currently looking into a workaround using archive mirrors for the packages, but that should not be the final solution and at least currently it seems not all repositories are available in the archives (at least yet).Some time ago, we already started on moving to Debian stretch, but did not continue, since we would lose Java 7 support, which we require for older Gerrit-versions.
While the images currently used by the CI will work for now, there won't be any updates to the images until this issue is fixed. Due to the way the communication between Jenkins and the slave containers is secured, these images will only work with the production system and not with any test instance or locally, if only one of the images is self-built. A short-term solution might be to tag the current images as legacy images, that will be used to build Gerrit-versions that still require Java 7, while we update the containers to Debian stretch for all other jobs. That means that the legacy containers will not see any updates in tooling anymore. The legacy-images might also stop to work, when the planned update to newer Jenkins versions will happen, but this is hard to tell.What do you think?Best,Thomas
--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
On 27 Mar 2019, at 09:44, Thomas Dräbing <thomas....@gmail.com> wrote:Dear all,Debian jessie is no longer supported [1]. For us that means, that the current build slave containers for the Gerrit CI cannot be built anymore. I am currently looking into a workaround using archive mirrors for the packages, but that should not be the final solution and at least currently it seems not all repositories are available in the archives (at least yet).Some time ago, we already started on moving to Debian stretch, but did not continue, since we would lose Java 7 support, which we require for older Gerrit-versions.
While the images currently used by the CI will work for now, there won't be any updates to the images until this issue is fixed.
Due to the way the communication between Jenkins and the slave containers is secured, these images will only work with the production system and not with any test instance or locally, if only one of the images is self-built. A short-term solution might be to tag the current images as legacy images, that will be used to build Gerrit-versions that still require Java 7, while we update the containers to Debian stretch for all other jobs.
That means that the legacy containers will not see any updates in tooling anymore. The legacy-images might also stop to work, when the planned update to newer Jenkins versions will happen, but this is hard to tell.
What do you think?
On 27 Mar 2019, at 10:18, Thomas Dräbing <thomas....@gmail.com> wrote:FYI:There is already a proposed change to discontinue with Java 7 and debian jessie by David Ostrovsky, which is quite old by now: https://gerrit-review.googlesource.com/c/gerrit-ci-scripts/+/207554It proposes to build older Gerrit versions (<= 2.13) with Java 8 with Java 7 as target, but as Luca commented on that change, we would be unable to run tests without a Java 7 runtime.
On 27 Mar 2019, at 15:44, Thomas Dräbing <thomas....@gmail.com> wrote:I suggested that some time ago, when reviewing this change: https://gerrit-review.googlesource.com/c/gerrit-ci-scripts/+/184730 .The question just is, whether the openjdk 7 from the experimental repository is stable enough to be used by the CI.
Since we still have a year until jessy loses its LTS-status, I would rather try to use this year to try to move everybody to a newer Gerrit version, if possible.
On Wed, 27 Mar 2019 at 16:26, Jonathan Nieder <j...@google.com> wrote:Hi,
Thomas Dräbing wrote:
> Some time ago, we already started on moving to Debian stretch, but did not continue, since we would lose Java 7 support, which we require for older Gerrit-versions.
Interesting. https://tracker.debian.org/pkg/openjdk-7 tells me a
recent version of OpenJDK 7 is available even for Debian experimental.
Would that be usable here?
Thanks,
Jonathan
On 27 Mar 2019, at 15:46, Luca Milanesio <Luca.Mi...@gmail.com> wrote:On 27 Mar 2019, at 15:44, Thomas Dräbing <thomas....@gmail.com> wrote:I suggested that some time ago, when reviewing this change: https://gerrit-review.googlesource.com/c/gerrit-ci-scripts/+/184730 .The question just is, whether the openjdk 7 from the experimental repository is stable enough to be used by the CI.Agreed. Best to just "tag" the current images for now than risking to have an unstable Java 7 build.Since we still have a year until jessy loses its LTS-status, I would rather try to use this year to try to move everybody to a newer Gerrit version, if possible.That would be ideal, Java 7 is largely deprecated and unsupported.
Debian jessie is no longer supported [1]. For us that means, that the current build slave containers for the Gerrit CI cannot be built anymore. I am currently looking into a workaround using archive mirrors for the packages, but that should not be the final solution and at least currently it seems not all repositories are available in the archives (at least yet).
On Wednesday, 27 March 2019 10:44:15 UTC+1, Thomas Dräbing wrote:Debian jessie is no longer supported [1]. For us that means, that the current build slave containers for the Gerrit CI cannot be built anymore. I am currently looking into a workaround using archive mirrors for the packages, but that should not be the final solution and at least currently it seems not all repositories are available in the archives (at least yet).I just wanted to say that using http://snapshot.debian.org/ could be useful here. IIUC, since this is concerning *build* container images only, it's kind of OK to use older versions of packages which may have security issues, because you would never serve a production system from it. Additionally, by setting up a time based snapshot as APT source instead of the regular ones, it also allows you to create fully reproducible Docker-container-image-builds (with some extra scripts like change timestamps, remove logs, see the debuerreotype project). That is actually also how the official Debian Docker images are rolled. I'm not saying we should go to that extend, but it might provide good well-tested pointers to ensure our Gerrit CI containers can always be rebuilt.
(I'd love to help out more with the gerrit-ci project, but I guess I'm limited by my time.)(By the way, together with Bazel's reproducibility features, this is showing amazing results for how me and my colleagues roll containers for production - they're fully reproducible.)
HTH
On 27 Mar 2019, at 10:18, Thomas Dräbing <thomas....@gmail.com> wrote:FYI:There is already a proposed change to discontinue with Java 7 and debian jessie by David Ostrovsky, which is quite old by now: https://gerrit-review.googlesource.com/c/gerrit-ci-scripts/+/207554It proposes to build older Gerrit versions (<= 2.13) with Java 8 with Java 7 as target, but as Luca commented on that change, we would be unable to run tests without a Java 7 runtime.
Thanks David for the changes.Let's check if people still running Gerrit 2.13 (e.g. the OpenStack guys) are really using Java 8 already.Also what to do about Gerrit 2.11 and 2.12. As Luca mentioned in an earlier email on this thread, at least 2.12 is still used by some.I am currently working on creating Debian-stretch based variants of the build-slaves and will start some tests on the test instance next week to ensure all builds will continue to work.I would suggest to move this discussion to another thread, since due to the title marking it as a CI-related topic I guess a lot of people might not read it and moving away from Java 7 should be discussed with a broader audience.
On Fri, 29 Mar 2019 at 00:25, David Ostrovsky <david.o...@gmail.com> wrote:
--
On Wednesday, March 27, 2019 at 11:25:34 AM UTC+1, lucamilanesio wrote:On 27 Mar 2019, at 10:18, Thomas Dräbing <thomas....@gmail.com> wrote:FYI:There is already a proposed change to discontinue with Java 7 and debian jessie by David Ostrovsky, which is quite old by now: https://gerrit-review.googlesource.com/c/gerrit-ci-scripts/+/207554It proposes to build older Gerrit versions (<= 2.13) with Java 8 with Java 7 as target, but as Luca commented on that change, we would be unable to run tests without a Java 7 runtime.Can we re-visit the reason for using Java 7 that was discontinued on April 2015: [1]?It is hard for us to get the OS support with this ancient Java version. And Gerritusers have the same problem (my guess is: nobody in the wild using Java 7, butonly Java 8). The solution is: we start building Gerrit 2.13 with Java 8, done.I changed Buck build tool chain to produce Java 8 byte code in: [2]. I don't haveaccess to Java 7 any more, but SSHD-tests were failing. In: [3] I bumped SSHDto the same version (1.4), as on stable-2.14, and now all tests are green: [4].If we adapt the CI to use Java-8 docker container for stable-2.13 we should beable to kill Debian Jessie container.
--
To unsubscribe, email repo-d...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-d...@googlegroups.com.
On 29 Mar 2019, at 20:37, 'Doug Robinson' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:Folks:On Friday, March 29, 2019 at 5:36:08 AM UTC-4, Thomas Dräbing wrote:Thanks David for the changes.Let's check if people still running Gerrit 2.13 (e.g. the OpenStack guys) are really using Java 8 already.Also what to do about Gerrit 2.11 and 2.12. As Luca mentioned in an earlier email on this thread, at least 2.12 is still used by some.I am currently working on creating Debian-stretch based variants of the build-slaves and will start some tests on the test instance next week to ensure all builds will continue to work.I would suggest to move this discussion to another thread, since due to the title marking it as a CI-related topic I guess a lot of people might not read it and moving away from Java 7 should be discussed with a broader audience.We're still running Gerrit 2.13 and Java 7 as are a number of our customers (their choice - sometimes it's very difficult to change these things).Would definitely appreciate it if we could keep Java 7 around just a bit longer.
THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED
If this message was misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this email or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this email message are the author's own and may not reflect the views and opinions of WANdisco, unless the author is authorized by WANdisco to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by WANdisco. Although WANdisco operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.
--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
On 29 Mar 2019, at 20:37, 'Doug Robinson' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:On Friday, March 29, 2019 at 5:36:08 AM UTC-4, Thomas Dräbing wrote:Thanks David for the changes.Let's check if people still running Gerrit 2.13 (e.g. the OpenStack guys) are really using Java 8 already.Also what to do about Gerrit 2.11 and 2.12. As Luca mentioned in an earlier email on this thread, at least 2.12 is still used by some.I am currently working on creating Debian-stretch based variants of the build-slaves and will start some tests on the test instance next week to ensure all builds will continue to work.I would suggest to move this discussion to another thread, since due to the title marking it as a CI-related topic I guess a lot of people might not read it and moving away from Java 7 should be discussed with a broader audience.We're still running Gerrit 2.13 and Java 7 as are a number of our customers (their choice - sometimes it's very difficult to change these things).Would definitely appreciate it if we could keep Java 7 around just a bit longer.Java 7 is gone already, not by our choice.
I believe you guys are running a fork of Gerrit anyway (see [1]) and you are free to keep supporting it.
The discussion was about the OpenSource version of Gerrit and whether we should keep on building it on Gerrit-CI, hence the prefix [Gerrit-CI] on the subject.
To unsubscribe, email rep...@googlegroups.com
On Fri, Mar 29, 2019 at 2:36 AM Thomas Dräbing
<thomas....@gmail.com> wrote:
>
> Thanks David for the changes.
>
> Let's check if people still running Gerrit 2.13 (e.g. the OpenStack guys) are really using Java 8 already.
I can confirm that OpenStack's Gerrit is running on Java 8 (and has
been since before the 2.13 upgrade as we were under the impression
that Gerrit 2.13 required Java 8).
+1Do we have some kind of mirror for build artifacts from the CI, other than the CI itself? It might be helpful for some people to at least still have access to the current artifacts for a while (especially plugins).
Especially, if we decide to remove jobs building Gerrit stable-2.10 - stable-2.12, since we can't switch to Java 8 for them.
Sent from my iPhone+1Do we have some kind of mirror for build artifacts from the CI, other than the CI itself? It might be helpful for some people to at least still have access to the current artifacts for a while (especially plugins).But if people have access to them, they’ll use it and we all have to support them. Without even a working build, how can we support them at all?
Especially, if we decide to remove jobs building Gerrit stable-2.10 - stable-2.12, since we can't switch to Java 8 for them.My understanding is that we dropjava 7 and all aupport for anything older than Gerrit 2.13, isn’t it?
On 2 Apr 2019, at 08:59, Thomas Dräbing <thomas....@gmail.com> wrote:On Tue, 2 Apr 2019 at 09:42, <luca.mi...@gmail.com> wrote:Sent from my iPhone+1Do we have some kind of mirror for build artifacts from the CI, other than the CI itself? It might be helpful for some people to at least still have access to the current artifacts for a while (especially plugins).But if people have access to them, they’ll use it and we all have to support them. Without even a working build, how can we support them at all?Good point. My point was more to have a kind of archive of artifacts that are expressly not supported anymore. But we should definitely not encourage people to stay on these versions. I am fine with not having one, just wanted to put the thought out here.
Especially, if we decide to remove jobs building Gerrit stable-2.10 - stable-2.12, since we can't switch to Java 8 for them.My understanding is that we dropjava 7 and all aupport for anything older than Gerrit 2.13, isn’t it?Yes, that's I think the idea.
On 2 Apr 2019, at 09:50, Thomas Dräbing <thomas....@gmail.com> wrote:Some kind of artifact repository would certainly be useful. I remember a recent mailing list thread, where a newer plugin version was not compatible anymore with a previous patch version of Gerrit 2.16 and when I looked on the CI a compatible plugin version was not available anymore.
But we digress. That would be a different project to tackle.