I want to script my Jenkins installation. I use always use the "stable" release of Jenkins (currently : 2.121.3), but I noticed that when I install the stable release, the update website (in admin > plugin > advance) is setted to "https://updates.jenkins.io/update-center.json" which is not the stable release. I have to change this setting to "http://updates.jenkins-ci.org/stable/update-center.json".
I want to do it automatically, by script. I know I can change this setting in the /var/lib/jenkins/hudson.model.UpdateCenter.xml file, but I prefere to use a Groovy script to do this.
But I cant find a way to change this settings in Groovy scriptbecause i'm not aware of the Jenkins/Hudson data model neither the Groovy syntax, I dont know how to change and save the setting.
I was also searching for something like this, I just solved this using groovy, hope this helps anyone else as well.
import hudson.model.UpdateCenter;
import hudson.model.UpdateSite;
import hudson.util.PersistedList;
import jenkins.model.Jenkins
site = "http://updates.jenkins.io/update-center.json"; // TBD: update as necessary
PersistedList < UpdateSite > sites = Jenkins.getInstance().getUpdateCenter().getSites();
for (UpdateSite s: sites) {
if (s.getId().equals(UpdateCenter.ID_DEFAULT))
sites.remove(s);
}
sites.add(new UpdateSite(UpdateCenter.ID_DEFAULT, site));
As for the current Jenkins core API version (>2.16X),
The UpdateCenter Javadoc and UpdateSite Javadoc do not display any method that allows to either add or update the update site.
The UpdateCenter Class source code confirms that the values of the update sites are actually loaded (I suppose at the start of Jenkins) with no possibility to alter the lists afterwards.
So I guess the only way to set a custom update site is to have a custom update site is to feed Jenkins with a custom hudson.model.UpdateCenter.xml at the start.
Here're a couple of observations that I made (please confirm or invalidate in the comments below, as I'm not 100% sure about these):
the custom update site must have id default
discovery of plugins seems to fail at first start. Jenkins must be re-started in order to discover plugins.
Related
We are trying to migrate code from Liferay 6.2 to Liferay 7.2, but we've hit a wall when it comes to service builder. We've followed the guide (changing the dependency-injector to ds, adding the #Component to impl classes...) but when we run a ds:unsatisfied command in the gogo shell, this appears:
Declarative Service {id: 5522, name: foo.**PersistenceImpl, unsatisfied references:
{name: Configuration, target: (&(origin.bundle.symbolic.name=foo.service)(name=service))}
}
Any ideas what is happening?
a couple of months late but here is what fixed our problems.
Basically we had to create a two new classes, one that implements org.osgi.framework.BundleActivator and another com.liferay.portal.upgrade.registry.UpgradeStepRegistrator.
Doing this, we force the table to update the version of the service and publish them to osgi.
A possible failure of "unsatisfied references" may be also in the case you used Service Builder and you changed the default package name (suggested by the process), but you did not update the other references manually.
In more details: I had the same issue, but after checking with Gogo Shell tool (Control Panel -> Gogo Shell and then write ds:unsatisfied), it figured out that there were some missing packages that should have been exported by the *-api component (hint: there is an *-api and a *-service component that are generated when you follow the Service Builder steps).
The fix
So, I went in the bnd.bnd file from the *-api component and checked the Export-Package entry. What I noticed was that, even though I have changed the package to totally something else, the Service Builder process did not care and used the same old default package (hint: it names them by appending to the name of the service the .exception, .model, .service and .service.persistence). Below is an example of my Export-Package property from the bnd.bnd file:
Export-Package:\
<my_service_name>.exception,\
<my_service_name>.model,\
<my_service_name>.service,\
<my_service_name>.service.persistence
Changind the <my_service_name> to the actually name of my package solved the issue.
Further reading: https://help.liferay.com/hc/en-us/articles/360018168891-Detecting-Unresolved-OSGi-Components
I am currently trying to automate the process of bamboo remote agent installation and uninstallation. I have run into a problem in regards to adding and removing capabilities.
What I am trying to automate:
(The following is what I do on the bamboo server via the GUI, I want to do this on the remote agent machine via bash script.)
I install the remote agent on a VM machine, then start it up. I go to the bamboo interface and click on the newly created agent's name.
I add a custom capability type, for the key I put 'buildserver' and for the value I put the name of the agent.
I add an 'Executable' capability of type 'Command' with Executable label 'cygwin' and path 'C:\cygwin64\bin\bash'
I navigate to the git executable, and remove it by clicking 'delete.' <--- (the problem step)
what I've done.
I have looked here and found a way to automate steps 1-3 using the following "bamboo-capabilities.properties" file:
buildserver="AGENTNAME"
system.builder.command.cygwin="C:\cygwin64\bin\bash"
However I am stuck on how I would remove the git capability (step 4.) I've tried something appending something like this to the file:
system.git.executable=""
but it does not seem to do anything. Does anyone know how I would do this? There seems to be very little documentation about this online.
Thanks very much.
I never found a way to get around this, but I found a workaround. I later learned the point of removing git in my situation was to allow a shared capability that was also called git to take precedence. My workaround was to set the non-shared capability to the value of the shared capability. I am not 100% sure that this does the same thing, and I am not in a position to test it yet, but as a capability seems to be only a key-value pair I don't see why it wouldn't.... will update if anything breaks.
I am deploying a SharePoint 2010 web part that uses the microsoft .net charting tool to build charts. I need the chart handler added to the sharepoint web.configs automatically. I've been told that when you create the wsp the package can be told that when the program is installed it needs to modify the web.config to add these handlers.
I have seen a couple options out there:
-WebConfigModifications
-Safe controls
I don't know which, if any, that I should be using. I don't know for sure if this will be a first time installation for the application (we're moving sharepoint environments at the same time we are updating this. I think that it will be a first time installation on that new environment but can't be sure.)
And I definitely do not know how to implement this correctly. I would appreciate any advice.
Also it may be important to know that I do not have any privileges on the server. I can't even deploy myself.
For example, this seems like good info: http://platinumdogs.me/2009/07/08/using-the-mschart-controls-in-sharepoint-moss-2007/ Except that I can't just write to the webconfig and restart IIS. It has to be automated and not a direct edit to the file.
Thanks all!
I would recommend that you use a Feature Receiver attached to your WSP to create the appropriate SPWebConfigModification entries when your solution's features are activated. Likewise, the SPWebConfigModification entries should be removed when your solution's features are deactivated.
Step 1: Create a Feature Receiver
MSDN has an overview of how to add a Feature Receiver: http://msdn.microsoft.com/en-us/library/ee231604.aspx
Note you'll want to handle both the FeatureActivated and FeatureDeactivating events.
Step 2: Use Feature Receiver events to add or remove SPWebConfigModifications
In those two events, you'll need to programmatically add or remove one or more SPWebConfigModification entries. These affect SharePoint's web.config file, but unlike a manual edit of the config file, they are stored in SharePoint's content database. This means that if the web.config is reset for any reason (and it happens), SharePoint can and will reapply the modifications, thus preserving your changes.
MSDN has an overview of programmatically creating and removing SPWebConfigModifications: http://msdn.microsoft.com/en-us/library/office/bb861909(v=office.14).aspx
It is very important that the FeatureDeactivating event properly clean up all modifications made during FeatureActivated, or you will end up with a proliferation of duplicate config entries. This means you need to really understand how to use the Path and Name properties of the SPWebConfigModification.
This article gives a good overview of how Path and Name are combined to create an XPath expression pointing to the node to be added or removed: http://smindreau.wordpress.com/2013/06/12/finally-the-way-to-add-web-config-modifications-to-sharepoint/
Step 3: Test, test, TEST!
Lastly, test activating and deactivating your solution's feature in your local development environment to make sure everything is working properly. Note that the modifications will be applied via a timer job, so you may need to wait a minute or two to see the changes show up. Be sure the feature deactivation cleans up your modifications! (If you get into a mess in your development environment with duplicate modifications, you can always wipe the slate clean with a little PowerShell action.)
I just attempted to update the site map provider from 3.3.6.0 to 4.0.14. I followed the instruction on the wiki however my SiteMapPath now renders empty. I made no changes to the mvc.sitemap file other than updating the schema to 4.0. When I debug into the SiteMapPathHelperModel I find that the model has no nodes defined. I am using the internal DI container (I would like to get this working before switching over to the application container).
When I check the sitemap.xml file it is well populated which makes me think that the mvc.sitemap is being read.
I'm out of ideas on this one and would be happy to provide any additional information which may be useful. I'm not even sure where I can hook into debug this problem. Literally the only thing I changed between a working 3.3.6.0 and a not working 4.0.14 was what was prescribed on the wiki.
Ok, since your /sitemap.xml endpoint appears to be working, you are correct the sitemap is being populated and loaded correctly.
There are a couple of things I know of that can cause this to happen:
If you are using Dynamic Node Providers, they must be added to a node that is not otherwise part of the sitemap. See my question here - I am trying to figure out why this is the case as well.
Your routes don't match your nodes - please read Routing Basics and/or post your routes and Mvc.sitemap XML.
If you check the above and everything appears to be correct, please make a small demo project showing a sample of your configuration and open an issue on GitHub, as it is highly likely your specific configuration has something to do with the problem.
BTW - You can debug by cloning the current repo on your system or downloading the solution as a zip, enabling NuGet package restore on your solution (right click the solution > Enable NuGet Package restore), add the MvcSiteMapProvider project to your solution, and then in your project remove the reference to MvcSiteMapProvider and add the reference to the newly added MvcSiteMapProvider project from your MVC project. Then you can add breakpoints and step through the code. I suggest making a backup of your solution (or ensure you can roll back another way) before doing this, and reverting back to your current state when done.
I have documented the whole procedure here: http://www.shiningtreasures.com/post/2013/08/21/debugging-an-mvcsitemapprovider-configuration
We have a SharePoint server that is version something like 12.0.4 and we are trying to import a site collection that was exported from another SharePoint server. The version there is somthing like 12.0.0. We have the export but we no longer have access to the server. How do we import the site from a lower version into a higher version?
We have tryed the stsadm import function but that is where we get the problem with the version mismatch.
has anyone experenced something like this?
Maybe there's a better way, but here's what I would just do because it can be done in the background, simultaneously to doing other stuff...
OK, both are version 12, so that would probably be just a diff in Service Pack levels / hotfixes etc. Set up your clean SP environment anew, without any service packs, updates, patches etc. Check the version number. If lower than your export, gradually perform updates until the version number is just identical. Import, and only after testing your imported content optionally apply other updates as you see fit.
And you don't have access to the original content database either?
If you do have that, simply attach the content database from stsadm and it will upgrade the database for you on the fly.
Check out this article for a detailed list of what version numbers correspond to which updates and patches of SharePoint.
http://www.mindsharpblogs.com/penny/articles/481.aspx
Can you check the actual version numbers in your farm? 12.0.0.4 corresponds to the RTM and Beta versions of SharePoint.
Let us know the exact version numbers on both ends if possible (if the text is in the error), and maybe we can recommend a more detailed solution.