I created a new project in Jenkins and when configuring made sure to uncheck the 'Let Jenkins Create Workspace' and 'Let Jenkins Manage Workspace View' boxes because I didn't want Jenkins to change my default workspace path (C:\workspace). However once a build was triggered it automatically changed the workspace path to C:\tools\Jenkins\jobs\project_name\workspace. Changing the path is unacceptable because a lot of my source files are dependent on the C:\workspace path.
Am I misunderstanding the function of the boxes I unchecked? How do I keep my path at C:\workspace?
I never used Perforce Plugin and I don't know what these checkboxes do. But normally if you want to fix workspace's path you can use Configure->Advanced Project Options->Use custom workspace checkbox. As described in documentation it does what you need:
Normally you should let Jenkins allocate and clean up workspace directories, but in several situations this is problematic, and in such case, this option lets you specify the workspace location manually.
One such situation is where paths are hard-coded and the code needs to be built on a specific location. While there's no doubt that such a build is not ideal, this option allows you to get going in such a situation.
Maybe you have to play also with 'Let Jenkins Create Workspace' and 'Let Jenkins Manage Workspace View' checkboxes.
Related
I have recently installed Jenkin autodeploy tool. But I want to change it's default workspace location path which is pointing to my installable directory(c:) but now I want to keep my all projects in other drive so for that need to change workspace location.
But in my jenkin portal I am not finding that option.
Can anyone suggest me where can I find that?
Please see screen shot as well.
See Here
Thanks
Vijay
This option was removed in 2.121:
Build Record Root Directory and Workspace Root Directory can no longer be configured through the UI as these options were generally unsafe to use while Jenkins was running. Instead, these locations can now be customized using system properties on startup. Existing changes to these options will be retained unless and until overridden at startup.
Further details under JENKINS-50164.
Under the new model, one sets the workspace root with the hudson.model.Slave.workspaceRoot system property, which can be set as follows:
-Dhudson.model.Slave.workspaceRoot=/whatever
The exact mechanism for setting a property like this varies by OS/platform, but many typical options are described here. The full list of available system properties is on the Jenkins Wiki.
Since I also couldn't find under Jenkins -> Manage Jenkins -> Configure System the Advanced option. Where you can add a different directory for Build Record Root Directory.
You can change this property directly in the config.xml in the root folder of your Jenkins.
Here you can update the property to what you need to.
I would recommend using the following structure,
/path_to_the_folder/${ITEM_FULLNAME}/builds
Because using ${ITEM_FULLNAME} in the path, will put the builds of every job into its own folder.
In jenkins, how do I design a plugin to take user's input on where to create the workspace on the filesystem?
I came across WorkspaceLocator but not sure how to use it. An example would be great.
[edit]
I want to be able to do this from the plugin's code. As in, for a particular type of project, the workspace should be created in some hard coded location that is declared in the code.
You can change the workspace at Advance Project options -> Use custom workspace under your job configuration.
I am using TFS 2010. In the build process template, I add a new workflow activity InvokeProcess to run a batch file. I need to set the working directory of this InvokeProcess to the workspace directory of the Build agent. Is there any way to do this?
Should be able to use workspace object. Just type workspace and intelisense will kick in. This is built in object that holds the path to the build workspace. Others available are sourcesdirectory and binariesdirectory. Spelling maybe wrong not in front of a pc
I follow this answer and get it resolved: https://stackoverflow.com/a/9564712/3918598
Basically, you will need to create a new local variable SourcesPath at the outter most scope and then consume it wherever you want. Do not name it SourcesDirectory because that name has already been used by some inner activities.
I have a single code based being used to build an application for multiple platforms.
Locally I have setup a main build-env.properties file, and a series of additional *.properties files that I use to switch settings for the different platforms I am publishing to.
Doing my build on the command line I simply use the command:
ant build -propertyfile dev-build.properties
How can I do this in Jenkins?
I currently use the "Invoke Ant" Build Step with the target set to build, but am at a loss for how to specify the secondary propertyfile?
Although not exactly the same, you can take the contents of those properties and put them into the Jenkins Invoke Ant build step, utilizing the properties advanced field.
The most basic way:
You will need to create a new task for each different set of sub properties you wish to utilize.
In your "Invoke Ant" build step, if you press Advanced..., this reveals a "Properties" field, you can copy the properties from one of your *.properties files into that field.
Repeat for each different properties file you wish to utilize.
Parametrized build plugin might help you. This is assuming the number of properties you are changing is one or two. So when you run a job, you get a drop-down to select you OS and go.
Though, as I have mentioned here , what goes against this plugin is that it makes the process manual
On this thread Hudson / Jenkins: share parameters between several jobs you can read the 2nd option in Anders's answer as an alternate approach.
A better approach for this is using a parameterised job with file parameter(refer to doc for creating the builds). Mentioning the file location as "propertyfile" would help. This would be better than reconfiguring the job again and again to run a build (To copy the properties file to the input location).
In the TFS 2010 build definition window, under “Process” there are two required items. They are “Configurations to build” and “Projects to build”. Under projects to build, it will allow me to enter something like:
$/TeamProject/Area1/Area2/*
However, this doesn’t seem to do what I expect. The build fails because it’s looking for:
$/TeamProject/Area1/Area2/Sources/*
What I am trying to achieve by this is to build all the solutions held under this area. For example, I have:
$/TeamProject/Area1/Area2/Solution1/Solution1.sln
$/TeamProject/Area1/Area2/Solution2/Solution2.sln
$/TeamProject/Area1/Area2/Solution3/Solution3.sln
There are many more solutions than this, which is why I’m looking for a way to build all solutions under the specified path recursively. Is there a way to do this in TFS 2010?
You can modify the process template. Expand it with the Matching files (I don't have the exact naming now) activity. Add a parameter that passes the information you set in the build defintion to the MachingFiles actvity. Then pass into the build solution activity instead of the argument that you enter in the build definition the files that is found by the MatchingFiles activity.
Now add a dummy solution in the build definition for the solution to build (it is not used anymore).
See the blog post series on the build customization for more information on customizing the build process template.
FWIW,
I've got: "configurations to build" blank
and under "projects to build" I've added my solutions via the ellipsis button
I would setup mappings for
$/TeamProject/Area1/Area2/Solution1/
$/TeamProject/Area1/Area2/Solution2/
$/TeamProject/Area1/Area2/Solution3/
Then in the build definitions enter the three projects to build
$/TeamProject/Area1/Area2/Solution1/Solution1.sln
$/TeamProject/Area1/Area2/Solution2/Solution2.sln
$/TeamProject/Area1/Area2/Solution3/Solution3.sln
You can leave the configurations to build as blank, or if you want to do a certain build you can set it to (for example) something like Debug|Mixed Platforms (check your Configuration Manager... for the solutions you are building to see what is valid)
Alternatively, you can just map the following (depending on how much you have in this folder, if you have Solutions 4+ that you don't want to trigger builds on, don't do it at this level)
$/TeamProject/Area1/Area2
And have one solution which contains the Solution1, Solution2 and Solution3, and build that instead.
By default building your Solution1 which is mapped to
$/TeamProject/Area1/Area2
On a build agent with a working directory that is going to looks something like:
$(SystemDrive)\Builds\$(BuildAgentId)\$(BuildDefinitionPath)
You'll end up with it being build under
C:\Builds\1\Solution1\Binaries
C:\Builds\1\Solution1\Sources
C:\Builds\1\Solution1\TestResults
Which is why you want to make sure that your OutDir's etc are all correct and not hard coded!
If you have a look while building, you'll see the build agent populating the Sources folder, and it should (if configured correctly) put all outputs into the Binaries folder (and then copy them to the Drop Folder configured under Build Defaults in TFS.