One of the mechanisms for deploying the assembly to Jenkins is to use artifacts to place the last binary file in a known place, and then start a new task (only with the success of the compilation / testing phase), which uses (protected private key) ssh or scp to copy artifacts to the test / production computer, and then complete the installation.
We use a similar mechanism for some automated testing that we do. The tricky part is getting the shell command to process the ssh keys, so we do the following:
eval `ssh-agent -s` ssh-add ~/.ssh/your_private_key_here
While this private key is on the Jenkins server, and the public key is on the server you are trying to click on, you can use the ssh and scp commands in the rest of the script to execute the functions on the server in question.
If you prefer to completely start the process from the destination server, you can create a small script that runs on the server that checks for new files in the artifact directory of your Jenkins build. Thanks to the latest path, you don't have to know the build number for this. To find the specific path, you can log in to your Jenkins server (once you have saved at least one artifact), and find the project you are using and look at the last successful artifacts that will be the URLs of the last successful collections of artifacts. These URLs remain constant and always indicate the most recent successful build, so you don’t have to worry about changing them if the project name or server name has not changed.
NOTE : there are security holes here that you can drive on a truck if you do this for anything other than deployment for testing. In the case of the first mechanism, your build server has an ssh key that gives it access (potentially destructive) to the target. In the case of the second mechanism, you trust that the Jenkins server will only serve binary files that suit you. However, for test environments, clicking on a scene, etc. These methods will work well.
gaige source share