Currently my TFS build is creating the workspace in build machine and all my remaining task are performed in a network share in UNIX machine. So i copy my workspace to that network share before proceeding with the build. Is there any way to directly create the workspace in NetworkShare, so that i can stop copying process.
If you mean the UNIX project have dependencies which generated on windows build, I am afraid you have to add a copy task to copy them first, unless you can build the windows and UNIX projects on the same agent, but generally it's not possible.
However if you want to build them on a network shared path, then you just need to deploy a new build agent and set the network path as the working folder. Thus you can directly reference the dependencies on the shared path.
Related
I am trying to copy war and ear files from windows share path(UNC) to linux target servers where jboss jvm is running and then deploy these files using our custom script. this is for applications that are still not using tfs to do their build. i tried download from file share task in azure devops but that is only copying to the agent location but not to the target server. if anyone has come across this situation and found a solution please do share your thoughts. appreciate it. thanks.
You need to use two tasks/steps to handle this situation.
Copy/download files from windows share path(UNC) to a folder path in build agent machine, such as $(Agent.BuildDirectory)
Copy files from a source folder to a target folder on a remote Linux server machine over SSH.
Since you have successfully download from file share task in Azure DevOps to agent machine. Then you just need to use Copy Files Over SSH task.
Use this task in a build or release pipeline to copy files from a
source folder to a target folder on a remote machine over SSH.
This task allows you to connect to a remote machine using SSH and copy
files matching a set of minimatch patterns from specified source
folder to target folder on the remote machine. Supported protocols for
file transfer are SFTP and SCP via SFTP. In addition to Linux, macOS
is partially supported.
More detail configuration about this task please refer official link here-- Copy Files Over SSH task
We have Jenkins Docker Slave template that successfully builds a piece of software for example a Gradle project. This is based on the https://hub.docker.com/r/evarga/jenkins-slave/).
When we fire up the docker slave the dependencies are downloaded everytime we do a build. We would like to speed up the build so dependencies that are downloaded can be reused by the same build or even by other builds.
Is there a way to specify an external folder so that cache is used? Or another solution that reuses the same cache?
I think, the described answers work only for exclusive caches for every build-job. If I have different jenkins-jobs running on docker-slaves, I will get some trouble with this scenario. If the jobs run on the same time and write to the same mounted cache in the host-filesystem, it can become corrupted. Or you must mount a folder with the job-name as part of the filesystem-path (one jenkins-job run only once at a time).
Here's an example for maven dependencies, it's exactly what Opal suggested. You create a Volume, wich refers to cache folder of the host.
I want to use existing TFS build scripts but move my code to the TFS cloud.
Can this be done?
Is it as simple as changing the "Source Control Folder" in the Build Definition? (I doubt it).
We have a local build machine which I want to use as it has custom installations required for the build to succeed.
You can. If you install and configure a TF Build Controller locally you can connect it to VSO. Add some agents and you can build hapily locally with all you code safe and secure in the cloud.
I am in Jenkins and using ArtifactDeployer. The console output tells me that the remote repo is http:// myrepo but all it does is create a new folder in my base directory which I also specify in this plugin. It correctly finds only one file to copy but strangely just creates a new directory and copies it in there. I thought this would enable me to deploy artifacts to another server... Can I do that?
No you can not do that with artifacts deployer but there are other ones you can use - read below:
Jenkins provides by default a feature for archiving artifacts generated by the build of a Jenkins Job. These artifacts are archived in the JENKINS_HOME directory. However, this directory contains also tool configurations (global and job configurations). Therefore, there is no separation between infrastructure data, jobs data and generated elements. It is often considered to be a bad practice and it doesn't help to manage it from an administrator point of view.
Unfortunately, it's not possible to extend the 'archived artifacts' feature to archive artifacts in a location other than JENKINS_HOME.
The main goal of the ArtifactDeployer plugin is to archive artifacts in your desired locations (other than JENKINS_HOME directory).
There are many Jenkins plugins close to ArtifactDeployer such as CopyArtifact plugin or CopyArchiver plugin for publishing artifacts from Jenkins resources (from the current workspace, from the old builds of the same job or other jobs, ...) to remote locations with the protocol file://
There are also others plugins for managing other protocols such as ftp://, ssh:///.
I have created a lightly customized TFS build process template and also appropriate TFS build definition. It builds fine on the TFS build server.
Is there any way I can allow developers to reuse the same build process XAML and definition to do full builds on their local machines? Maybe there is some utility which can be run with TFS build process XAML files?
I really would like to avoid maintaining a separate copy of the build script for full local rebuilds.
The build templates can only be run by the TFS build service. Without installing that on each developers machine, that might not be the best idea.
An alternative is to setup a share on the developments machine and grant access to the TFS Build account (the one that TFSBuildServiceHost.exe runs on the server as). Then the developer can Queue a build and get the Server to Drop the files onto their machine.
The downside to this is you need a lot of builds to be run on the Agents.