Closed (fixed)
Project:
Hostmaster (Aegir)
Version:
7.x-3.x-dev
Component:
Jenkins
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
28 Oct 2011 at 19:26 UTC
Updated:
7 Jul 2016 at 11:44 UTC
Jump to comment: Most recent
Comments
Comment #1
steven jones commentedIf you can figure out how to keep the old versions around, then we can test this quite easily.
Comment #2
steven jones commentedOver to Mr Debian.
Comment #3
steven jones commentedOkay, so this really isn't perfect, but during releases, could we actually test the upgrade by installing using the stable channel, and then change the channel to testing, and then upgrade the package.
This should actually perform the upgrade that would be done if we issued the pull command on the repo,
yes?
Might this be better than nothing at the moment, as is easily scriptable.
Comment #4
anarcat commentedI don't actually know how to do this, to be real clear here. :)
You seem to have a great idea. We could have a "stable to testing" test, or "stable to unstable".
The problem with that is it can't test 1.0 to 1.5, for example, but maybe that's a good start already.
The one thing i was thinking about is that we can generate debian packages on the fly and install them directly... But i'm not sure how this plays with the cloud...
Comment #5
steven jones commentedSo we can't configure the repo to store old packages somehow? I'm not familiar with debian packaging at all really!
Seems a bit lame if you can't grab a package from an 'archive' somehow.
Comment #6
anarcat commentedWe *could* keep all old packages though, by running reprepro with --keepunreferenced. The problem though is that apt-get is not going to find those files - apt repositories can only reference a single version per release. So we would need to wget the file manually, which defeats the whole purpose of having an APT repo in the first place... might as well build the package by hand and upload it into the vserver.
Comment #7
ergonlogicCould we have multiple releases then? Code-names or suites mapping to our older release tags, maybe?
Or, worst case, multiple repos?
Comment #8
anarcat commentedWe do have multiple releases: stable, testing, unstable. So what Steve proposed for that is fine.
The issue is that we want this job to be able to test arbitrary release upgrades. Which necessarily means (A) rebuilding 2 packages from tags (not a problem) and then (B) installing the first package and upgrading to the second package in a vserver (that's the part i am not confortable with).
If someone can give me a script that would do (B), I can do (A).
Comment #9
steven jones commentedOkay, so my script for #3 is done: http://ci.aegirproject.org/job/U%20aegir%206.x-1.x%20deb%20upgrade/
Comment #10
anarcat commentedThat's cool!
Now we need a script that would do something similar but instead of taking "stable" and "testing", would take .debs.
The hairy part there is probably that apt-get can't deal directly with .debs. The way "pbuilder" does this is using those two commands:
Here pbuilder-satisfydepends-dummy.deb would be aegir.deb, aegir-hostmaster.deb and aegir-provision.deb...
Comment #11
steven jones commentedWe do now indeed test this using Jenkins, and we can test the upgrade using debs, I think the hard part is going to be parametrising the upgrade, and getting it to install/generate the correct debs before installing the latest ones.
Comment #12
helmo commentedI would love to see this happen.
I've added #2148183: Parameterize puppet for testing Aegir upgrades to get some technical discussion going.
Comment #13
ergonlogicNew features need to be implemented in Aegir 3.x, then we can consider back-porting to Aegir 2.x.
Comment #14
helmo commentedWe have this now ...
U_aegir_7.x-3.x-stable-to-unstable-deb-package