Additional Build-Node for Tycho-CI

Summary

I'd like to connect one (or more) dedicated build agent as described here to the Tycho CI Server

Please let me know how to proceed here and what information are required from my side.

FYI @akurtakov @mistria

Please provide:

• server name
• server description (e.g. OS, arch, etc)
• server IP
• user name (e.g. jenkins)

We will create an SSH keypair and send you the public key. Once the public key is in place, we can set up the agent in Jenkins.

• Name: Läubisoft GmbH Build Node
• Description: Debian Bullseye 11 (64 bit), hosted by https://läubisoft.gmbh/en/

Should I post IP+Port+Username here as well or on a more confident channel?

IP, port and username will be visible in the JCasC config in the JIRO GitHub repo.

assigned to @fgurr

• Name: Läubisoft Build Node
• Description: Debian Bullseye 11 (64 bit) dynamic build node hosted by https://läubisoft.gmbh/en/
• User: buildnode
• IP: 109.239.48.216 (port 22)
• Executors: 4
• Labels: linux, centos-8

Thanks. Mail with public key has been sent.

Key is added now to authorized_keys file

I already see the node but it gives an error message: https://ci.eclipse.org/tycho/computer/laeubisoft%2Dbuild%2Dnode/

Sadly I can't read it whats the cause because of

laeubi@laeubi-soft.de is missing a permission, one of Agent/ExtendedRead, Agent/Connect is required

We can handle additional permissions for dealing with Jenkins agents on Monday.

Great, I just wondering if there is some interval for the agent where it is retried to connect? The build machine is usually offline if not used (e.g. at night) or restarted (e.g. to acquire a higher resource level).

We can handle additional permissions for dealing with Jenkins agents on Monday.

You have the following additional permissions now:

• "Agent/Connect"
• "Agent/Disconnect"
• "Agent/ExtendedRead"

Great, I just wondering if there is some interval for the agent where it is retried to connect? The build machine is usually offline if not used (e.g. at night) or restarted (e.g. to acquire a higher resource level).

It can be configured. Defaults are:

• Maximum Number of Retries: 10
• Seconds To Wait Between Retries: 15

Great this works like a charm now!

changed title from Additional Build-Slave for Tycho-CI to Additional Build-Node for Tycho-CI

@fgurr the node is running now, many thanks!

Thanks @fgurr for the setup, and thanks as well @lmisingnamem8k for bringing new computing power to Tycho!

for bringing new computing power to Tycho!

At the moment I'm struggling a bit with the configuration so at the moment there is not much additional power, but hopefully I'll sort that out soon :-)

@fgurr I noticed that the "declarative tool install" seems not working as desired, is there possible no install sources configured or is this intentional?

We can set the agent/build node specific tool locations for JDK, Maven, etc. That should help.

Wouldn't it be more useful to instead have a docker container with the slave configured in the container? I've previously used that mechanism in another open source project, see https://github.com/cgeo/cgeo-executor. It's a container that automatically runs an agent of a predefined Jenkins master. That way everyone could anonymously contribute CI power.

The benefits would be:

• The docker container can fetch secrets defined by the eclipse admins in a safe way without sharing them with the person running the container.
• Additional tools for the Jenkins agents can be installed in the container, instead of relying on them being available on the real new machine, or on Jenkins installing them somehow at runtime.
• Avoids a huge variety of Jenkins agent OS, version etc. Especially nice when updates and changes have to be done.

Sounds interesting. Can you create a separate issue for this?

@mkeppler I'm not sure if it is really 'safe' to share secrets just because it is a docker-container can you explain how it is supposed to work? I think if there is a safe way (the git-steps seem to use interactive auth for this) it should work regardless if the node is a container or a "real" machine?

Wouldn't it be more useful to instead have a docker container with the slave configured in the container?

Sure I'm just using what Eclipse offers here but not bound to it, but I think this would require that arbitrary executors can connect. On the other hand it won't require a public IP.

Additional tools for the Jenkins agents can be installed in the container, instead of relying on them being available on the real new machine, or on Jenkins installing them somehow at runtime.

Actually that's what the declarative tools install is for, but you need to configure it in jenkins that it can be installed automatically see http://www.mtitek.com/tutorials/tools/jenkins/img/configure-tools.png for example, so if the tool is not there it will be installed automatically, seems that this is not configured currently.

We can use this ticket also to get some experience with that when everyone is back on monday

I played around with the build node and it works quite well.

Things that would be useful:

1. remove the centos-8 label (was just for testing), the label linux seems to include an additional ',' also add an external label (see also #1111 (comment 648634)) so one could better control where jobs are run (e.g. for deployment I assume it must run on an EF node)
2. if team members (or 'owner' of the node) could set nodes to online/offline to allow ordered shutdown/boot

1. Done
2. Done

I assume this as 'done' I think we can solve other issues separately.

closed

mentioned in issue #4276 (closed)