Is it possible to configure a Gradle remote cache from the command line or on the daemon?
Ideally I'd like to configure our build server to use a remote cache without requiring all users of my build server to update all of their settings.gradle files.
I could also inject the required lines into the settings file if it doesn't exist potentially. I can't find any documentation so that leads me to believe this could be a bad idea.
Likely you'd do this with an init script, specified on the gradle command line with --init-script
See https://docs.gradle.org/current/userguide/init_scripts.html
Related
How does the config file provider plugin work?
I have a Jenkinsfile for a declarative pipeline (multi-branch build) that contains:
configFileProvider([configFile(fileId: 'maven-settings', variable: 'MAVEN_SETTINGS')]) {
sh 'mvn -B -s $MAVEN_SETTINGS -DWHERE="$WHERE" deploy'
}
I have tried running this on two different Jenkins installations one which is installed directly and runs as daemon and another running as a container (jenkinsci/blueocean).
When run on the direct the Jenkins Config File Provider plugin is able to provide the required settings.
provisioning config files...
copy managed file [Maven settings] to file:/var/lib/jenkins/workspace/redacted#tmp/config8989354118161621860tmp
When run under the jenkinsci/blueocean container it fails with:
provisioning config files...
not able to provide the file [ManagedFile: id=maven-settings, targetLocation=null, variable=MAVEN_SETTINGS], can't be resolved by any provider - maybe it got deleted by an administrator
I have created a managed maven-settings.xml file with id maven-settings for blue/ocean but it is not being picked up.
I've also tried copying it to ~/.m2/settings.xml
By contrast the working installation does not have any managed files (settings.xml or otherwise) and I am unable to locate any maven settings file in the workspace. I'm not sure what the #tmp directory is. It is deleted by the time a build finishes.
So my question is:
Where should I put the settings to make the configFileProvider pass them on for the jenkinsci/blueocean build job?
How does the config file provider plugin work?
I have no idea what its doing so its hard to debug. The source is here but Java, Maven & Jenkins are not my main area.
What differences are there when Jenkins itself run as a container?
This answer suggests the the config file provider is unnecessary.
There is a similar question which is unanswered but it relates to a maven plugin.
I have part of the answer. My maven-settings file wasn't being picked up because I was using the file name rather than the file Id which is different.
The remaining part of the question is how is the original Jenkins instance able to generate this file without it being listed as a managed file.
I'd like to build certain projects without the use of of Gradle daemon. I've read that this can be done either by command-line argument --no-daemon or by changing Gradle properties under .gradle/. I need to disable it for just some of the projects I build under the root project though.
Is it possible via settings.gradle/build.gradle settings or am I better off making custom build script?
You can simply add org.gradle.daemon=false to a gradle.properties file in the project root folder.
The daemon documentation mainly talks about disabling the daemon altogether on a machine but the gradle properties documentation indicates that the location where a property / value pair is declared is irrelevant, they are sourced from different location, with overwrite rules.
I have TeamCity installed on centos. I have only one Linux BuildAgent for now. My build configuration execute a maven script and using ant upload WAR artifact to Windows Server on FTP. After this step i have to execute BAT file on remote Windows Server. I read that i can do this using psexec/RemCom, but i can't understand how i can do this in TeamCity? Build Step or different Build Configuration should contain steps to execute psexec/RemCom or i can insert Build Step into existed Build Configuration?
Single build configuration could potentially consists of multiple build steps. Think of them as a actions you would like to do. So I suppose that right now you have a maven step in your build configuration. I would suggest you to add Command Line step, where you can do what ever you want -- it's like bash/batch script. You can put script contents directly to the build step, or you can write script and execute it.
But as you mentioned that you have CentOS, it could be you have to do extra configuration on the build agent for PsExec to be available.
I am in process of moving configuration parameters out of Java application. I discover that the best approach is to extend your classpath and use .properties files (leave ZooKeeper alone for another requirement).
So my WAR file no longer have any hosts/IPs/URLs, users/passwords.
DevOps distribute configs manually across test, stage, stable installations.
Now time for Jenkins to run tests. But they fail as there are no required .propeties files in classpath.
How can I load this config files to Jenkins and how to make in available in test classpath?
maven-surefire-plugin allow extending classpath and passing system-properties.
So only question how to get separate directory in Jenkins hosting server and load files to this directory and create alias/placeholder/envvar per build job to refer to this path in build config.
This job can be done with SSH access, but I think that this is "wrong way". I expect that this can be done via Jenkins UI (any manager can upload file in WEB browser).
UPDATE I have no requirements for distributed slave/master builds but it whould nice to have solution that migrate configuration files to slaves automatically...
In this way sshing to host or ftp/scp - bad thing.
I read most of Jenkins docs, ask at mail list and IRC. Yea - Jenkins community is silent. At docs I found link to Config File Provider Plugin, after that I visit http://builder.evil.com/jenkins/pluginManager/available page and look for config keyword.
There are a lot related plug-ins with various usefulness to my subject (most useless first):
https://wiki.jenkins-ci.org/display/JENKINS/Envfile+Plugin - This plugin enables you to set environment variables via a file.
https://wiki.jenkins-ci.org/display/JENKINS/Credentials+Binding+Plugin - Allows credentials to be bound to environment variables for use from miscellaneous build steps.
https://wiki.jenkins-ci.org/display/JENKINS/Environment+Script+Plugin - Allows you to run a script before each build that generates environment variables for it.
https://wiki.jenkins-ci.org/display/JENKINS/EnvInject+Plugin - This plugin makes it possible to have an isolated environment for your jobs.
https://wiki.jenkins-ci.org/display/JENKINS/Copy+Data+To+Workspace+Plugin - Copies data to workspace directory for each project build.
https://wiki.jenkins-ci.org/display/JENKINS/Copy+To+Slave+Plugin - This plugin allows to copy a set of files, from a location somewhere on the master node, to jobs' workspaces. It also allows to copy files back from the workspaces of jobs located on a slave node to their workspaces on the master one.
https://wiki.jenkins-ci.org/display/JENKINS/Config+File+Provider+Plugin - Adds the ability to provide configuration files (i.e., settings.xml for maven, XML, groovy, custom files, etc.) loaded through the Jenkins UI which will be copied to the job's workspace.
Only last plug-in - Config File Provider Plugin allow editing configs via Jenkins WEB interface. And it have brother - Managed Script Plugin - for uploading/managing/editing custom scripts. No question now I use Config File Provider Plugin!
You should keep the configs required for the tests together with the rest of source code, so that after compilation, your unit tests can run.
After deploying the .war, the DevOps team should overwrite the in-war configs with whatever per-environment configs that they have.
how can I copy the artifacts from Teamcity to another server?
Thanks
The way I have done this, make things a lot easier.. Setup another configuration that pulls in, via artifact dependencies, all the files you need then run a cmd script to xcopy/copy the files to another drive on the network. You can do this using cmd script, vbs, python, shell etc..
Remember, you only need to refer to directories as if they were local as you would have your script in the same working directory
i.e cmd script :: xcopy .\"my build artifact(s)" \path\to\drive\on\my\network\"my build artifacts"
It doesn't get easier than that.
Naturally, if your artifacts are huge, then you may want to consider your more complicated option. However, TeamCity currently have a ticket pending, which you can vote on, that allows you to run multiple runners in one configuration - so you could just add your cmd script to the same configuration to save the copy time; please vote if can spare a minute:
http://youtrack.jetbrains.net/issue/TW-3660
There is a Deployer plugin, that supports deploy by fileshare/SMB, FTP, SSH and other means. The usage is basically the same as the Artifact paths.
We have used just samba, so you must enter:
target Host path: //server/drive/myfolder
Username: mydomain\myusername - in our case we had to write domain
here too
Password: ****
Domain: mydomain
and in path just select the files as in artifacts:
product/* => product.zip
and it will create file //server/drive/myfolder/product.zip
You can do it from your build script or externally.
If you are looking to get artifacts copied from a remote build agent to the primary TeamCity server, you may want to look into configuring Build Artifacts under the General Settings.
According to TeamCity's wiki entry on BuildArtifacts (http://confluence.jetbrains.com/display/TCD7/Build+Artifact) "Upon build finish, TeamCity searches for artifacts in the build's checkout directory according to the specified artifact patterns. Matching files are then uploaded ("published") to the TeamCity server, where they become available for download through the web UI or can be used in other builds using artifact dependencies."