Hudson slaves how to access the workspace

How to configure the system to have one master and several slaves when building regular c-code using gmake? How can subordinates access the workspace from the wizard? I assume the NFS share is the way to go, but if that is not possible, choose other options?

http://wiki.hudson-ci.org/display/HUDSON/Distributed+builds is, but can’t understand how workspace sharing is handled?

Rsync? From the master: SCM task β†’ done β†’ rsync for all subordinates β†’ build the task, and if the workspace was performed on the subordinate β†’ rsync back to the master?

Any proof of concept or real solutions?

+4
source share
3 answers

When Hudson launches the assembly on the node slave, it checks the source control on the node. If you want to copy other files from the node wizard or copy other elements back to the node wizard after assembly, you can use Copy for the Slave plugin .

+4
source

This is certainly a late answer, but may help others.

I am currently using the "Copy Artifact plug-in" with excellent results. http://wiki.hudson-ci.org/display/HUDSON/Copy+Artifact+Plugin

( fooobar.com/questions/157408 / ... )

+2
source

Only one way to do things, others exist.

Workspaces are not actually distributed when distributed to multiple machines, because they exist as directories on each of several machines. To decide the coordination of items, any item that needs to be distributed from one workspace to another is copied to the central repository through SCP.

This means that sometimes I have a task to wait when planting items in the central repository. To fix this, I have the task of running a shell script that polls the repository through SCP for the necessary elements, and it is wrong if the elements are not available after five minutes.

The only drawback of this is that you need to pass a parameter (build number) to save assemblies on one page, not allowing one assembly to collect the previous version of the artifact. This and you must configure many SSH keys to avoid having to pass a password when running SSH scripts.

As I said, this is not an ideal solution, but I believe that it is more stable than the ssh artifact capture code for my specific version of Hudson (and my set of SSH servers).

One drawback, SSH servers of most Linux machines do not seem to have performance. A solution like mine tends to swamp your SSH server with a lot of connections coming in at about the same time. If you find that the same thing happens to you, you can add timer delays (simple, imperfections), or you can rebuild the SSH server with high-performance fixes. Once I hope that high-performance patches break into the base code of the SSH server, provided that they do not adversely affect the security of the SSH server.

+1
source

All Articles