-
Improvement
-
Resolution: Fixed
-
Minor
I've found that jenkins-plugin-manager-1.0.1 fails when not used against updates.jenkins.io. For example, the Cloudbees update center fails because that site has no update-center.actual.json file available there. There seems to be is an update-center.json for all of the update centers.
The actual file has pure json content while the non-actual file has a wrapper around the json which is "updateCenter.post( ... json goes here ... );" Someone said that has to do with allowing the file to be more easily compatible with browsers use of javascript.
I don't know if the best thing is to get Cloudbees to add the non-actual file or change the code to remove the wrapper text in in the non-actual file and use it.
[JENKINS-60214] Plugin installation manager does not work with other update sites
It seems silly that you need to modify a response before you can use it, would be good for cloudbees to add the JSON imo
Well, processing data is what we do with these things under our hands 
.
Back to my point about the "source of truth", I still quite believe the fact the tool does not use what Jenkins does is a pretty important thing?
leemeador
added a comment - I found some bugs in the 1st PR after it was merged:
1) If you use the command line option to supply an experimental update center, it generates an incorrect URL from which to load the update-center.json. (There is an improper "update-center.actual.json" embedded it it.)
2) If you supply an update center that has a long URL, such as the version specific update centers at cloudbees, it does not generate the correct URL for loading plugin files. The old algorithm was just removing the last part of the URL and finding plugins below that path.
leemeador
added a comment - I found some bugs in the 1st PR after it was merged:
1) If you use the command line option to supply an experimental update center, it generates an incorrect URL from which to load the update-center.json. (There is an improper "update-center.actual.json" embedded it it.)
2) If you supply an update center that has a long URL, such as the version specific update centers at cloudbees, it does not generate the correct URL for loading plugin files. The old algorithm was just removing the last part of the URL and finding plugins below that path. 
Though we could ask to add this on CloudBees side, I think the right way is to actually not use the .actual.json, since this is the other file that Jenkins uses/relies on. So IMO it would be safer to use the file that Jenkins instances are downloading.