Open gdams opened 4 years ago
I thought I'd taken the docker tag off that machine - I'll remove it now as the docker builds generally run on other systems now
It's sitting with two executors as well which should have prevented it from blocking any pipelines (I also thought I'd dropped that back to one executor, or did you increase it to unblock the installer jobs?)
Have dropped executors on that machien back down to 1 now that the docker job has finished (and the docker
tag removed this time!)
Do we have docs on the requirements setting up machines for running the installers @gdams? The only thing we need to take care of is additional access controls on machines that have the keys so I don't want them just installed everywhere (same situation with the docker keys - I want access to those systems more restricted than most of our systems so I'm trying not to deploy them everywhere at the moment)
If I can do anything to make things more friendly for our infra, please let me know.
@aahlenst This is purely out of curiosity (as itr's not a problem) but why is java 11 required? There seems to be references to gradle in there, but does that now require 11 - is that the reason?
Java 11 isn't required anymore. I removed the Java 11 specific features a year ago or so. The machine the jobs are running on doesn't have 11 anyway?
It does have 11 installed (most of our machines do) but it's not the default java. Your first link was where it said it needed java11 or later, so I was curious as to why that was the case, or if java 8 was ok for whatever required it. Sounds like the latter, in which case perhaps the doc could be updated to clarify that?
I think we should definitely get an ansible role set up for those extra things (ruby gems+fpm), even if we don't run it by default on all of our machines :-) Feel free to take a look at creating one if you're interested, or @Haroon-Khel can probably get something in place without too much difficulty too! I suspect there's an ansible operation to install a ruby gem somewhere so this should be a simple thing to add.
I think it also requires a specific GPG key to be installed on the machine
Yeah I figured there probably was hence my earlier comment on "additional access controls" - I'm not keen for any such key being a default thing on all the machines
@sxa I think there is a Jenkins plugin that allows you to install a gpg key on a machine temporarily for a job
could look at using https://plugins.jenkins.io/rpmsign-plugin/
I think it also requires a specific GPG key to be installed on the machine
Seems to be the ones in ~/.gnupg
on the machine that are used
@sxa @gdams aside from the prereqs listed in https://github.com/AdoptOpenJDK/openjdk-installer/tree/master/linux#prerequisites, which of the existing roles do you think would need to be run on a machine dedicated to only building linux installers? I can start adding these roles into a playbook
I would imagine that nothing else would be definitely required to perrform the work, but I would suggest we add the Superuser
and jenkins
roles and see how well that works :-)
We should see if we can run the install script excluding the signing on a machine set up with only those things.
The linux installer job uses gradle tasks, yet gradle isnt mentioned as a prerequisite in https://github.com/AdoptOpenJDK/openjdk-installer/tree/master/linux#prerequisites. @gdams Do you know if this is because Jenkins sorts this out by the use of a plugin?
@Haroon-Khel Gradle wrapper is being used. If Gradle is already present on the system, it's ignored.
Is this still relevant with the move to the linuxNew
installer process?
For those watching, linuxNew has been renamed to linux
Currently we only have 1 machine to build the den/rpm files and this is shared with the docker builds. This can cause a massive delay in getting releases out. Let’s get the required dependencies added to ansible.