You can install a current Jenkins yet still have it use a legacy JVM?
[#] Mon May 14 2018 14:40:16 EDT from LoanShark @ Uncensored
Current jenkins must run on Java 8.
Therefore, if you're hosting it on Ubuntu via openjdk, you'll need Ubuntu >= 16.04.
It's also possible to install Java <=7 on Ubuntu 16.04, but only via the previously-mentioned openjdk PPA (which has a few backport issues with timezones), or via the Oracle released which is EOL'd, or via the extended-support Oracle release.
This Java <=7 is not used for running Jenkins itself, which requires Java 8. But it can be used in a more limited way for building Java projects that are incompatible with Java 8; basically, your Java8 Jenkins is forking a Java7 child process in this case. Jenkins Freestyle projects work fine for this purpose. I think Jenkins Maven-mode projects also have some limited support in this area, but there are definitely issues that may require moving to Freestyle, and I'm having trouble remembering all the details at this point.
Hrm... so pushing a slave.jar out to the client and expecting it to work with Java <= 7 doesn't really sound like an option, which was what I had hoped to do.
I have to instead do the nfs/ssh-script thing.
[#] Mon May 14 2018 15:21:11 EDT from LoanShark @ Uncensored
2018-05-14 14:53 from fleeb @uncnsrd
Hrm... so pushing a slave.jar out to the client and expecting it to
work with Java <= 7 doesn't really sound like an option, which was what
I had hoped to do.
Not sure what you mean by this.
From Jenkins, click on 'Build Executor Status', then 'New Node'. Create a new node as a 'Permanent Agent'. Go to 'Launch method' and select 'Launch slave agents via SSH'.
This pushes a 'slave.jar' file out to the client machine and executes it to establish the slave.
At least, it did in version 2.32.3. Maybe things are different in the current versions.
[#] Tue May 15 2018 14:19:15 EDT from LoanShark @ Uncensored
Can you upgrade your slave to include java 8? I know you might be thinking that you'd need to upgrade your OS distribution to something that includes openjdk8, etc, but an alternative is the Oracle release that should run on some older distributions
I've tried installing Oracle's Java 8 on the machine, but it won't run. I think they built their VM on something a tad more modern than this machine.
Rightfully so, frankly. But frustrating for me, heh.
I also took a look at building OpenJDK on the box, but that looks formidable (in that the build environment has dependencies that also pose problems).
[#] Tue May 15 2018 14:45:03 EDT from LoanShark @ Uncensored
No, you don't want to try to build openjdk as a backport. Supported distributions or nothing.
My suggestion would be that you can continue to use the jenkins master to kick off jobs when something is checked into source control--jobs can run on the master as well. the job should be a small script that just SSHs over to your slave and builds the stuff that you need built on old distros.
Or you can hire a new build monkey.... *runs*
[#] Tue May 15 2018 14:48:06 EDT from LoanShark @ Uncensored
alternate possibility... ensure that all jenkins masters or slaves are running java 8. upgrade distribution if necessary, etc.
do the builds within a Docker environment (or, failing that, a simple chroot jail) that's based on a much older userland.
so that way it's all running locally, no sshing across the network to build hosts that must be maintained on some ancient distribution.
This is probably the more sustainable, long term supportable path since you'll no longer have hardware dependencies related to old distros. All virtual.
[#] Tue May 15 2018 15:00:50 EDT from wizard of aahz @ Uncensored
Or you can hire a new build monkey.... *runs*
I thought that they already had one.
Hehehehe. Well done LS.
As if this cheap-ass company would hire anyone else.
The docker idea is interesting... I don't have much experience reaching out of the docker environment and into the host environment, but it seems like one ought to be able to nfs locally that way or something.
Twisty, but probably sustainable.
I have another subject of bitching, though.
This ODBC thing originated on Windows, I believe, but has a reasonable unix variant in 'unixodbc'. It's good enough that you can write code once and have it work with databases across both operating systems and engines reasonably well (as long as you aren't attempting to do anything particularly fancy).
Unfortunately, back in 2011, unixodbc decided to release a libodbc.so.2 when they added a SQLLEN for 64-bits (if I am reading this correctly). That is to say, they provide a minor ABI change to add a new function, but rather than naming the so libodbc.so.1.1 or something, they jump to libodbc.so.2.
Even on http://www.unixodbc.org/ itself, they say "So if after installing you have apps that can't find libodbc.so, it's likely they are linked to libodbc.so.1, so just create a symlink from libodbc.so.2."
It's funny in some ways. Elsewhere in the internet, you can see some people waxing poetic about how OpenOffice should "Do the right thing" and link to the major version of libodbc instead of libodbc.so, because obviously if the major version changed than they're taking a big risk, yadda yadda yadda... not even realizing that unixodbc themselves kinda did the wrong thing, probably causing OpenOffice to do that.
It's annoying to me, though, because I have to package something that needs to account for this.
I suspect I'm going to do something else. Link to libodbc.so.1, and if I can't find it (but can find libodbc.so.2), symlink in my own lib and hope I find it.
Go to page: ...