I have an Ivy job that recently after I updated Jenkins and all my plugins started creating new workspaces each time the job builds. Anyone know why? The new build folders names match 'Execute concurrent builds if necessary', which isn't choosen.
Thanks
I found your post while trying to find an answer to this problem for myself. This seems to be a bug in jenkins version 1.540. I rolled back to the LTS version [1.532.1], and its no longer creating multiple workspaces for ivy jobs.
We had to use the ivy feature "Use custom workspace" and just put a path to where the normal workspace is. I heard of people talking about the issue (would need to hunt to find it). Hopefully it get patched.
I was able to update Jenkins (and Ivy plugin) to the latest version (1.564). I believe the cause was this issue:
IVY plugin issue 14
Which concerns not releasing workspace locks and most likely caused new work-spaces to be created. Just update Jenkins, and from Jenkins update the Ivy plugin as the fix is already in plugin version 1.24.
Related
I'm trying to set up a build using Multibranch. I'm basically having the same problem as stated here, but our SCM is Subversion. The Bug in the Bitbucket Branch Source Plugin as described here can therefore be ruled out, especially since our Jenkins has the newest version installed anyway.
I tried to find a similar ticket regarding my problem, but couldn't find one, so here I am.
As this particular project is configured in a way that configuration files (including something like the Jenkinsfile) are to be stored in a subfolder, I don't know what else to try, apart from configuring individual jobs. I'd rather stick to using Multipipelines, however, as they help keeping the build jobs tidy.
My jenkins jobs started to disable by themselves when the svn checkout fails. I explored previous builds and they never disabled when failed. This new behaviour is not desired for me.
The message in the new build log is as follows:
...
One or more repository locations do not exist anymore for myJob1, project will be disabled.
The project has been disabled
ERROR: Failed to parse svn info for 'repourl'
...
I downgraded the jenkins Subversion plugin which was recently updated, and the multi scm plugin as well. However, the problem remains.
Any suggestion?
That message is coming from the Blame Subversion Plugin. Is it possible you recently installed that plugin? Or that you recently turned on SVN blame as an option?
I think this is an undocumented(?) behavior of the Subversion Plugin to automatically disable a job if the SVN URL is not valid (anymore). This behavior seems to be implemented for several years now, as this discussion from 2012 indicates. I just learned about this behavior only after moving a SVN project to a different folder which caused my project to be disabled. I did not find any information on how to disable this behavior.
Update 2021/09:
The behavior is apparently still present and there seems to be no way to disable it.
There is a corresponding feature request on the Jenkins JIRA though: JENKINS-10922
Please vote for this feature request!
AEM muti-module project has pom.xml at each module level. Version can we changed at that level, new build shows the artifacts with updated version.
With versions, there would be a new AEM Package created for each version. We would want to uninstall/delete the old package before installing new version.
Question is, how can we handle the uninstallation/deletion part of old package (new package to be installed is of different version) in CI-CD job? We could think of following solutions
Query the list of packages to get the version and use that to uninstall.
Pass version as parameter to Jenkins Job in "Build with Parameters". But automatic build trigger on code check-in could have issue.
Has anyone faced similar situation? Please share if there is best practice which is followed for AEM CI-CD jobs for handling different release versions.
Querying the list of packages is your best option I think. You can collect any previous version of your package then, no matter when you deployed that specific package to that server the last time.
An alternative option might be to delete the package immediately after installing it, but I fear there might be lots of problems waiting for you then:
Some packages need a restart, you may not delete the package to early, ...
As I said, I would go for the querying solution.
I have a Jenkins Server (1.510) on Win 2008 with ~100 jobs.
After installing and then uninstalling the CloudBees (Plugin_1, Plugin_2) set of plugins + restart I have the following issues:
half of the Jobs are now missing.
many plugins are not functioning well, for example the green-balls plugin is not working and also the entry to launch the backup plugin is missing
many built in Jenkins buttons such the new "Credentials" is missing from the "Jenkins Configure" Menu.
Looking at the FS, i still see all the jobs.
I already tried :
Using the reload configuration
Reinstalling the plugins
Reinstalling Jenkins with the same version once again
Still the jobs are missing
Any idea how to solve it?
Thanks,
Doron
When job is loaded, many of the related Java classes get instantiated. If instantiation fails, usually because some plugin has been removed and that class is no longer available at all, then the job is hidden.
I suspect you have accidentally removed some other plugin too.
Note: Before actually doing anything, take full backup! Easiest is to backup entire Jenkins folder, where the jobs, configuration etc reside.
Easiest solution might be to just install Jenkins from scratch, install the plugins you do need (see below for troubleshooting if you're missing some), then copy the jobs subfolder to the new Jenkins. It might be best to do any configuration under Manage Jenkins by hand, but you can also just try copying the related XML config files.
If you are missing a plugin and can't figure out which one, you should look at jenkins.out.log and jenkins.err.log log files and search for exceptions happening after Jenkins is started. That may give you a clue on what plugin you are missing.
You can also try editing the job XML files to remove build steps you identified from the exceptions (remember to take backups first!), then restart Jenkins or select Reload configuration from disk from Manage Jenkins page.
If not solved, but you find relevant-looking exceptions or something else interesting, please update the question with details.
After I upgraded Jenkins, one of my jobs disappeared. I found out that although my job directory still existed, the config.xml file inside had somehow gone missing.
I restored this file from a backup, after updating all the plugins that needed updating, and reloaded the configuration, and the job reappeared in Jenkins.
I am on a redhat linux box. I recently updated Jenkins to version 1.509 only to find that after doing so it has "forgotten" two of my jobs/projects. The jobs can still be found on my Jenkins machine under /var/lib/jenkins/jobs, but they no longer show up in the Jenkins GUI. I attempted to re-create them based off the configuration file I have, but I am not confident I have totally re-created the functionality they had.
I also tried to copy the job and or rename it hoping that would get jenkins to see it, but no luck. I had tried cp -r /var/lib/jenkins/jobs/JOB1 /var/lib/jenkins/jobs/JOB2. I also restarted the service a number of times. Finally I updated all of my plugins on the off chance that was somehow related.
So my question is "How can I get Jenkins to notice these jobs?" or failing that "can I run these jobs from in the terminal?"
NOTE: I am not discouraging others from upgrading Jenkins. After I upgraded Jenkins did complain about a number of things which I didn't pay enough attention to which I believe got me into this mess in the first place.
If I were you, I would try the Jenkins CLI (from $JENKINS_URL/cli) and use the create-job command and feed the job configuration file to the cli's stdin.
If that does not help, I would inspect Jenkins log files (you are saving stdout and stderr of Jenkins somewhere, right?) for any errors or clues. If the job failed to load because of some tag that you can guess is provided by a plugin, try to remove that part from the config file.
If that does not help, I would upgrade Jenkins. I think there might be some fixes related to this in the LTS version changelog since 1.509.
And above all... if I were you, I would start making backups of the job configuration files.
I regularly back up the global config.xml, all the job config.xml files and all the plugins. Using these I can set up my Jenkins from scratch. And I do that to set up a test instance where I try any plugin or Jenkins core upgrade. If I see no problems after running a few of the trickiest builds, I know I can upgrade the production instance with much more confidence.