I am setuping a Jenkins environment to manage workflows of Python projects. This Jenkins install is running on a Windows 7 machine and I need to backup the Jenkins config to avoid potential loss of work in case of HDD failure (for example).
I tried the SCM sync configuration plugin but this one is not compatible with the Subversion plugin I use and caused Jenkins to display only a white screen when I activated it. So it is not usable.
I also tried the thinBackup. It works well but, due to Jenkins being ran as a local service, it is not able to save backups on a network drive (and backuping on the same drive than Jenkins is not very insteresting). You would think that I just have to run Jenkins with a network user, but in this case it would not have sufficient local privilèges.
I am thinking about creating a Batch (or Python) script which could deal with SVN to backup the Jenkins configuration by adapting what is described in this page but I am not very happy to write a SVN account password in a Batch (or Python) script which could potentially be seen by anybody.
So I would know if it exists an other way to achieve this Jenkins configuration backup.
Or at least, does it exists a way to perform svn commands without showing anybody a clear password?
The issues with the SCM sync configuration plugin sadden me, too. What we do with our Jenkins instances, is: we use thinBackup to run regular backups and store them in the default folder on the same HDD. Then we have a daily cron job rsync them with a folder on another HDD. So if Jenkins is running on Windows, you would probably achieve the same using the Windows Task Scheduler and cwRsync, for example.
Related
I have a Jenkins server at CloudBees server and it has a lot of jobs.
I have created new Jenkins server at AWS Ec2 instance.
Now, I need to migrate all Jenkins jobs from CloudBees to New Jenkins Server(AWS EC2instance)
How can I do this task? Is there any way to migrate all jobs by CLI?
Use Backup Plugin or thinBackup
You first need to ensure that you do not use proprietary CloudBees features (RBAC, Folders+ plugins). This is the only thing that's really specific to migrating from a CloudBees Jenkins.
After that, standard steps for migrating Jenkins apply:
ensure that you have same plugins installed on the new Jenkins
align credentials and credentials-IDS
API tokens need special handling
After that, you can just copy all $JENKINS_HOME/jobs/*/config.xml files (if using folders, copy recursively).
You can also copy job configs via CLI or REST API, but usually the fastest way is to copy directly on filesystem level.
Currently, I am working in a quality process so as to ensure that the code is acceptable. For that, I'm integrating Jenkins, SonarQube and GitLab, which are running in different servers (actually they are in different docker containers).
The idea is to check with SonarQube everytime the code is pushed against GitLab and block commits, merges, and so on, whether SonarQube has not passed.
I have already integrated Jenkins with SonarQube, but Jenkins checks the code inside his workspace, so imagine a situation where a developer in his laptop needs to push his changes.
My conceptual question is simple: Is it possible to integrate these technologies in order to do this? And, if the question is yes, which steps are necessary?
PD: I don't need to see code, configuration files,and so on. I just need something like:
Configure SonarQube to work with Jenkins
Do an script so as to copy that file in that folder,
...
First, in docker means each tool is in its own container.
They only need to see each other through the network, which is where a Docker Engine in Swarm mode comes in.
Second "configure Jenkins to work with SonarQube"... that is what I have done in my shop, and there isn't much to it.
Once the Jenkins SonarQube plugin is installed, and the address for the SonarQube server entered, you can configure your job and call sonar (for instance with maven: $SONAR_MAVEN_GOAL -Dsonar.host.url=$SONAR_HOST_URL)
The analysis done in the Jenkins workspace will then be published in the SonarQube server.
A swarm server is the more modern version of this 2015 docker-compose.yml file from the marcelbirkner/docker-ci-tool-stack project.
The idea remains the same though: each element is isolated in its own container.
I haven't tried It myself but https://gitlab.talanlabs.com/gabriel-allaigre/sonar-gitlab-plugin could be interesting in your setup.
I have recently started to mess about with Jenkins and am unsure how to deploy my web app to a basic server. I've gotten into the Pipeline (https://jenkins.io/doc/book/pipeline/) and it seems like a fantastic way to work.
Where I'm a bit stuck is in two spots:
Once my repo is in my workspace within Jenkins, how do I prep it so I am only deploying the files necessary for the application? For example, I don't need my src/ directory or my Vagrantfile when I'm deploying things.
How do I deploy my app to the server? I see examples all over the place, but I am getting a bit lost since there seems to be so many ways to do this. I'm assuming scp or something like that...?
To build off of #2, is there a way to deploy web apps as transactions (in one shot) rather than file-by-file?
Please let me know if I can provide any information for potential answers!
I can't speak to your specific use case but a common way to do this is the build-and-deploy model, where you will have 2 Jenkins jobs. The "build" job will check out from source, run build commands such as maven or make, and lastly will "archive" the build artifacts. The latter is an option under the 'post-build actions' tab at the bottom.
In the "deploy" job, you will grab the artifacts of your choice. You can fetch a single file, all of them, and everything in between. This requires use of the 'Copy Artifact' plug-in and it allows you to copy files generated by other jobs. Now you can run your usual deploy script in the 'Execute Command' box. Most command line paradigms are supported out of the box such as setting environment variables.
The instructions above assume that you want to run your application off of a host that you've provisioned as a Jenkins slave.
Use artifacts as mentioned by Paul Back, or a 3rd party artifactory server as in video
This is always tricky and error-prone. Why not spin up a fresh server with new release (humanly verified once)
Jenkins & Ansible is the answer here. This is how I deploy to production, since I am in no need to use anything like Docker (too many issues with particular app) so have to run the app natively. Quick example would be
You monitor a specific branch in gitlab / github or whatever else and then call a webhook on push / merge etc on that branch, at this point you deal with anything you need to do by running a playbook on the jenkins job that monitors that branch (jenkins).
in my case jenkins and ansible run on the same server. Jenkins runs the ansible playbook that does whatever I need to do.
for example with ansible, I copy certain files that need to be there, run configs / change filenames etc. setup nginx, run composer,
you get the point.
I recently started working in a way for speeding up the building time of a relatively big software code base of my company. This code base is using RTC for source code management and after looking and trying I ended using jenkins for automation of the process. I started by creating my build server in a local machine and configure the repository through the RTC plugin, which works quite well using the poll SCM option and with the workspace repository-rtc option. However, I have to move this job to the official jenkins company server, but keeping the job execution in the original local PC. I have added the PC as a jenkins node and I have not had any problem with reaching it through jenkins, but my question/assumptions are the following:
It looks like the job is executing the RTC buildtoolkit from the slave (or at least I had to configured the RTC path in the node.
For some reason, it looks like the polling in jenkins is always looking for the repository in the master, even when I add a SCM pre step in which I can validate that the job is running in the slave system.
My question: Is there any way of ensuring the polling happening in the slave (without scripting or adding external solutions, just using RTC plugin)? For security reason I cannot add additional plugins to jenkins or to create anything in the master, I only got a free job to configure.
Thanks.
I am in the process of migrating a Jenkins server from an internal resource to AWS EC2. I have completed the copying of all files in /var/lib/jenkins. However, when I start Jenkins it immediately wants to run builds, and they all fail because I need to make some changes. Devs don't like the tons of emails.
How do I start Jenkins with all jobs/builds disabled by default, so I can test and configure things before cutting over to the new server installation?
Here is a useful link! This groovy script needs to be placed in $JENKINS_HOME/init.groovy