Please make the Jenkins installer use a _STATIC_ package
|Assignee:||Johannes Wienke||% Done:|
|Category:||Recipe||Spent time:||9.66 hours|
|Target version:||Toolkit 0.1|
Today I wanted to convince a colleague to make use of the new tool chain, aka toolkit-distribution using recipes via local Jenkins, instead of the Gar-Installer (which my colleague is used to and which he really likes) to distribute his components. After explaining him the advantages of the "new" approach he was willing to try it.
Again, the Jenkins bootstrapping failed because some plugins couldn't be fetched (Git, Build-Flow), which I only found out by checking the Jenkins config via Jenkins GUI. Comment of the the colleague:
"Okay, at this point I would already be lost..."
Additionally, somehow Jenkins is not able to find the Plugin repository (Jenkins version is: Jenkins ver. 1.532.2) so I really wasn't able to create all Jobs because the build-generator fails, again, because Jenkins was not setup correctly.
IMHO this is basically A SHOW STOPPER we will not be able to convince people to use our new tool chain (I am fully convinced it's the right way to go) if the setup already fails, especially because Jenkins is such a central component.
I really don't blame the implementation/developer of the installer script, dynamic web-based fetching of plugins is simply
a "fragile" thing.
I would like to vote for a hosted tar.gz file including all the required plugins and Jenkins itself.
Configure update site correctly
Despite using the LTS update site for first plugin installation, the one
configured inside jenkins was still pointing to the trunk plugins. This
commit also configures the URL for the LTS plugins.
Make installed folder relocatable
Removed the absolute location from the starter script.
Fail in case a plugin could not be installed
In some cases the jenkins CLI does not indicate an error if a plugin
could not be installed. In order to still catch those error, actively
check for the each new plugin being installed.
Fix job generator symlink
Use a relative path to be relocatable
Do not block in case jenkins does not start
Fix plugin verification step
Some plugins were only available after a restart of jenkins. However,
the verification process was performed immediately after installing.
This was a race condition. A restart was added.
#1 Updated by Florian Lier almost 9 years ago
- Description updated (diff)
#2 Updated by Arne Nordmann almost 9 years ago
- Status changed from New to Feedback
I kind of agree, this still feels fragile (well, it is some kind of prototype). I managed to use by just re-doing it one or two times and then the plugin installation went well. At some point I installed the required plugins by myself ... but I agree, this is not very usable and a showstopper.
So if we could go for a archive with the latest Jenkins LTS and stable versions of the plugins, that would be very nice. I like the idea.
#3 Updated by Florian Lier almost 9 years ago
- File jenkins_failed_download.png added
This is exactly the problem (see attached image).
Thank you for your comment Arne!
#4 Updated by Jan Moringen almost 9 years ago
Same thing happened during LSP-CSRA code sprint. In that case, the error seemed more permanent and plugins had to be manually copied from a previous Jenkins installation.
#5 Updated by Johannes Wienke almost 9 years ago
- Status changed from Feedback to In Progress
- Assignee changed from Florian Lier to Johannes Wienke
I will try to fix some things so that we can build a jenkins job from this.
#6 Updated by Florian Lier almost 9 years ago
...do you think this will solve the problem? I mean, if the job is red, because some plugin couldn't be fetched, that won't help when you really need it, e.g., when introducing the tool to someone.
Maybe I didn't get your point.
#7 Updated by Johannes Wienke almost 9 years ago
The job may fail sometimes, still the last valid archive will be preserved by jenkins. I think that's better than nothing.
#8 Updated by Florian Lier almost 9 years ago
...I think that's a nice option.
#9 Updated by Johannes Wienke almost 9 years ago
Wooooaaa, I can't even really test this because the jenkins web infrastructure is soo brittle.
#10 Updated by Florian Lier almost 9 years ago
;) Welcome to my world
#11 Updated by Johannes Wienke almost 9 years ago
I can't finish this today. Someone from the jenkins team has to fix the infrastructure first.
#12 Updated by Florian Lier almost 9 years ago
I just pulled recent changes, I like the new messages, feels a lot better to actually see what's going on, I also like the Security Warning.
#13 Updated by Johannes Wienke almost 9 years ago
That means the installation succeeded? I never managed to get there ;)
#14 Updated by Florian Lier almost 9 years ago
Yes, so far the installation worked, I am currently adding jobs via generator. The only question I have in mind is: If you enable security, meaning you need to login, is the build generator still able to add jobs?
#15 Updated by Jan Moringen almost 9 years ago
The build-generator can authenticate. See output of
#16 Updated by Florian Lier almost 9 years ago
Yeah, that's great. We need to document that I guess. Does the Drupal Auth also work? How did you manage ;) Because I the documentation is not very clear on that one.
#17 Updated by Florian Lier almost 9 years ago
Job Generation worked! Good "Job" Johannes :)
#18 Updated by Johannes Wienke almost 9 years ago
- % Done changed from 0 to 90
A jenkins jobs is now available and installation has been fixed as much as possible. Can someone please test the archive before I add a description to the wiki page:
#19 Updated by Sebastian Wrede almost 9 years ago
Nice. Does the static package already get pushed to some publicly available location?
https://ci.toolkit.cit-ec.de/job/jenkins-distribution/ is not available from outside of the university network (IIRC) or is otherwise currently not available (also not when connecting via VPN).
#20 Updated by Johannes Wienke almost 9 years ago
It wasn't even really tested so far and I don't have a location. ;)
#21 Updated by Johannes Wienke almost 9 years ago
So where should this be uploaded? Seems to be working now.
#22 Updated by Florian Lier almost 9 years ago
ci.toolkit is not the best idea since it can't be accessed from everywhere (i.e. externals)
#23 Updated by Sebastian Wrede almost 9 years ago
What about pushing it to the toolkit web server (toolkit.cit-ec.*)?
#24 Updated by Florian Lier almost 9 years ago
I could add an account on the toolkit (toolkit.cit-ec) machine that has limited rights, configure a section in the web server cfg and add a "copy via ssh" build step in the job that creates the *.tar.gz
If there is no veto, I'd like to go with this.
#25 Updated by Johannes Wienke almost 9 years ago
Sounds ok to me.
#26 Updated by Florian Lier almost 9 years ago
Now, the CI generated *tar.gz is scp'ed on the toolkit machine and available via:
#27 Updated by Florian Lier almost 9 years ago
- Status changed from In Progress to Closed
- % Done changed from 90 to 100
The file is avail under: https://toolkit.cit-ec.uni-bielefeld.de/dist/jenkins.tar.gz