Looking for help on the issue that we are facing with the deployment of the war that is generated through maven build. Unable to install or update the application. According to logs the previous application server is not even being stopped though environment properties are being set in the ‘application-config.properties’ file during the deployment process to stop the previous server and start a new one.
If you need more details, please contact us.
Application config specifications:
Combination of struts(version 2.1.8) and spring(version 2.5.6) framework.
Java 1.8 version with web sphere version 6.1 and dynamic web module version 3.1
Maven-compiler-plugin version 3.7.0 and maven-war-plugin 3.2.1.
Related
We run a Bitbucket Server on version 7.21 and have recently developed a Plugin for it. Since this plugin finally reached a stable Version we wanted to integrate it into our cd/ci pipeline (bamboo).
We can build the plugin via bamboo build plan alright, but we are facing an issue when trying to deploy it.
atlas-sdk's "atlas-install-plugin" does not work for us (afaik) because we are not in the project space, but only have the built jar itself.
Is there any way to copy the jar to a specific location on the bitbucket server and it auto-deploys or something similar?
For anyone searching, I found the solution.
You can install plugins via the rest api: https://confluence.atlassian.com/confkb/installing-uninstalling-upgrading-and-downgrading-marketplace-apps-on-confluence-using-rest-api-1005343959.html
After moving Jenkins to a new computer I cannot upgrade plugins since it thinks the new version is older than the installer.
I get the following message:
Some plugins could not be loaded due to unsatisfied dependencies. Fix these issues and restart Jenkins to re-enable these plugins.
Dependency errors:
Static Analysis Utilities (1.96)
Update required: Maven Integration plugin (2.12.1) to be updated to 2.17 or higher
Update required: Matrix Project Plugin (1.6) to be updated to 1.7.1 or higher
Update required: OWASP Markup Formatter Plugin (1.3) to be updated to 1.5 or higher
and several more.
I then try to upgarde Maven INtegration polugin (and alla others) it looks like the are installed and Jenkins is restarted. But I get the same error again.
When looking in the plugin folder I see that I have several version of the plugin. I try to remove the different folders and then detect that the old verision is still used even if the new version is available in the folder.
In the pluginmanager/installed the Maven Integration plugin is listed as version 2.12.1 and the possibility to DOWNGRADE to 3.8. 3.8 is the version that I upgrade to.
My conclusion is that during the move of the .jenkins folder to the new computer the dates of the old plugins are getting new values which confuses Jenkins. Is that a correct conclusion? How can I correct it?
Since the folder dates were changed long ago at the old computer I was not able to zip the old .jenkins folder with "correct" dates
However, I found a way forward anyway. I did like this:
Started with a newly installed Jenkins version.
Made sure I had all necessary plugins in the new Jenkins installation
Copied the following folders from the old computers .jenkins zip file:
jobs
nodes
secrets
users
workspace
Then I also moved the files in the .jenkins folder
I have a large fleet of Jenkins instances running in a cluster, all having the LDAP plugin version 1.6 (Jenkins version 1.611). I want to fleet-upgrade the LDAP plugin version to 1.7 (to incorporate environment variables in my plugin configuration). How do I achieve this without manually uploading 1.7 version through UI for each Jenkins instance?
I tried writing a script which basically performs these operations for each Jenkins instance:
Replace the existing .jpi/.hpi file in $JENKINS_HOME/plugins for ldap plugin with the correct .hpi file (of the 1.7 version)
Edit config.xml under $JENKINS_HOME which has the version number
Safe restart Jenkins
It works fine till step 2 but as soon as I perform safe restart, Jenkins magically puts in the original .jpi/.hpi file (the 1.6 version file) back inside $JENKINS_HOME/plugins. Jenkins instance has the 1.6 plugin version again in the UI. Is there a better way to perform fleet plugin upgrades in general? I want to mention that I want the 1.7 plugin version, not the latest
How do I fix this? I even tried using curl (mentioned at https://stackoverflow.com/a/20848745/1746529) but didn't help.
Got a working answer on Google groups.
"As you are on 1.x create an empty ldap.jpi.pinned file as a sibling and that marker will instruct Jenkins not to replace with the bundled plugin."
Came across the documentation for it as well - https://wiki.jenkins-ci.org/display/JENKINS/Pinned+Plugins
When installing a new Grails from Jenkins web UI, a user is given the choice of some versions - up to 2.4.4 and 3.0, but 2.4.5 and 2.5 are missed.
How to add 2.4.5 to that list?
P.S. Jenkins 1.598, Grails plugin 1.7 (latest)
There is an automated process within the Jenkins project infrastructure which updates the list of available versions daily.
Your Jenkins installation periodically downloads this file and uses it to populate the version list in the web UI.
Unfortunately, at the time of asking this question, that automated process was broken.
You can either wait for the bug to be fixed (it is now), or there should be the option to "Install from .zip/.tgz" instead of "Install from mirrors", where you can enter the URL to the Grails 2.4.5 zip file.
You have to go to "Manage Jenkins"/"Configure System"/"Grails installations" and put there the path where your installation is.
I've been working with a grails 1.3.7 project within STS for the last few months.
Our test and production environments use JBoss 5.1.
I upgraded our grails app to 2.1.0 recentlly and it all ran ok locally.
Major problems occured when I deployed it to our test environment (Jboss issues).
So in order to avoid this in future I would like to develop locally using JBoss also.
Is there a Eclipse/STS plugin I can use for this?
Thanks
Don't think there's a specific plugin for jboss
Seems your only options now are tomcat and jetty, if you need to stick with the 'run-app' command
If you can give up the debug console and check your test info at the browser, then you can probably write a small script to auto-deploy to a local jboss server, which you can set up through eclipse workspace