i have installed the thinbackup plugin to backup jenkins but as i have left the exclude option empty it is including all the files i never wanted to backup,so now i knew that if i use an expression like
^.*\.(log)$
it will not include the files having extention as .log but now the situation is i want to exclude a whole folder and struggling to get the regular expression for it.
what i have tried is
/jobs or jobs/*
Need help!!
Thanks in advance
I don't think you can do that with thinBackup plugin. However, Backup Plugin does what you need and much more. Once you've installed it, just go to Jenkins > Backup manager and enable Configuration files (.xml) only. Above that you will see a box named Custom exclusions. Here you can specify comma- or space-separated list of file/directory names to exclude from backup. See snapshot below:
You should also check the Backup content section shown above to include job workspace, if required. Even that has option to include/exclude files/directories.
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.
I have a set of projects in a folder in Jenkins 2.32.1 and I want them all (in this folder) to have a couple of environment variables loaded when the build runs. Is this possible? I have the folders plugin and had a look but didn't see anywhere to configure that.
Yes, it's possible, see https://wiki.jenkins.io/display/JENKINS/Folder+Properties+Plugin
A Jenkins plugin which allows users with config permission to define
properties for a folder which can then be used by any jobs contained
within it or any of its sub-folders.
Yes, this is possible. From Manage Jenkins, find Global properties. Under there is a checkbox for Environment variables. Select List of key-value pairs and add yours.
...according to CloudBees, that feature is available in the "non-free" Folders-Plus version. go.cloudbees.com/docs/cloudbees-documentation/cje-user-guide/…
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.
One of the tips Burt Beckwith provides when creating plugins is to delete files you don't use.
So if you don't use UrlMappings.groovy - delete it.
I was wondering about directories. If you have no controllers, should you delete the controller directory?
Thanks
The short answer is "Yes, you should." Looking at some of the other plugins you can see this is pretty standard practice. For example the Redis plugin on GitHub.
You can delete directories, but they'll get re-created after running various scripts, in particular package-plugin. I tend to remove them as source folders in GGTS so they're not distracting - I like to only see directories that are being used. I used to use an Ant script to do various build tasks for plugins, but at this point all I use them for is the post-package-cleanup task that deletes unused folders, e.g .https://github.com/grails-plugins/grails-spring-security-core/blob/master/build.xml.
It turns out that only three plugin files are required - all of the rest can be deleted if they're not used. These are the plugin descriptor, application.properties (although this is only used to specify the Grails version), and BuildConfig.groovy. BuildConfig.groovy might be optional too if you don't need to publish the plugin to a repo and have no dependencies. At a minimum it's needed to specify the release plugin, but if you don't need that they you can probably get by with just 2 files :)
I've added an svn:externals to my project, and it works great locally via TortoiseSVN. When I use Jenkins to pull from the same repository, it's not showing anything about the externals in the console output.
I read some other questions on here and I made sure my SVN version number in Jenkins was set to (1.6 externals to file) and restarted Jenkins. The problem is still occurring. Any ideas of something else I could set, or something I could use for troubleshooting? Thanks.
Oh, and the external directory is in the same repository, so I don't think it's an authentication issue as it builds fine without a reference to the external files.
I fixed this issue by selecting higher SVN Version Number on Jenkins 2.222.1.
Here is the procedure:
Manage Jenkins -> Configure System -> Subversion Workspace Version
Select at least v1.6. (The default one was 1.4 for me)
I may have had a very uncommon structure, but here's what worked for me...
First of all, here's the directory structure:
--Parent
----folder1
------subfolder1
------svnexternalfolder
----svnexternalfolder
As you can see, I had my svn external folder in two different levels of the project structure, but the Jenkins project was pointing directly at "folder1".
When first configured, it would never pull the files for my svn external folder (whether it was a full checkout, or svn update). This was configured with the svnexternals at the parent level.
My next try was to remove the svn externals at the parent, then specify just the higher location on the parent, then the lower location on folder1. This gave an error since the child svn directory had the same name as the other one.
So I flip-flopped the order of creating the svn external locations and did the child first (on "folder1"), then did the higher one on parent. Once I did that, everything started working.
Hope this helps someone else.
If you're curious about why I configured the directory structure this way, this was a PhoneGap project. apparently cordova/phonegap projects create their directory structures like this, the common folder beneath the parent is the "www" which houses all html, javascript, etc files, then those are also used under the platforms/ios, or platforms/android folders (in my example, I just called it folder1).