Right now only the Debian installs are tested in Jenkins. It would be nice to also test the upgrades from the previous release.

The hard part here is that the debian install tests rely on the packages being available in the debian archive - since the debian archive keeps only the latest versions, it makes it hard to test upgrading from previous releases.

Comments

Steven Jones’s picture

If you can figure out how to keep the old versions around, then we can test this quite easily.

Steven Jones’s picture

Assigned: Unassigned » anarcat

Over to Mr Debian.

Steven Jones’s picture

Okay, 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.

anarcat’s picture

I 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...

Steven Jones’s picture

Assigned: anarcat » Unassigned

So 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.

anarcat’s picture

Assigned: Unassigned » anarcat

We *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.

ergonlogic’s picture

Could we have multiple releases then? Code-names or suites mapping to our older release tags, maybe?

Or, worst case, multiple repos?

anarcat’s picture

We 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).

Steven Jones’s picture

Status: Active » Needs work
anarcat’s picture

That'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:

    $CHROOTEXEC dpkg --force-depends --force-conflicts -i "$BUILD_DEP_DEB_DIR/pbuilder-satisfydepends-dummy.deb" || true
    $CHROOTEXEC aptitude -y --without-recommends -o APT::Install-Recommends=false "${PBUILDER_APTITUDE_CHECK_OPTS[@]}" -o Aptitude::ProblemResolver::StepScore=100 -o "Aptitude::ProblemResolver::Hints::KeepDummy=reject pbuilder-satisfydepends-dummy :UNINST" -o Aptitude::ProblemResolver::Keep-All-Level=55000 -o Aptitude::ProblemResolver::Remove-Essential-Level=maximum install pbuilder-satisfydepends-dummy

Here pbuilder-satisfydepends-dummy.deb would be aegir.deb, aegir-hostmaster.deb and aegir-provision.deb...

Steven Jones’s picture

We 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.

helmo’s picture

Version: 6.x-1.x-dev » 6.x-2.x-dev
Issue summary: View changes
Parent issue: » #1080590: Testing [meta]
Related issues: +#2148183: Parameterize puppet for testing Aegir upgrades

I would love to see this happen.
I've added #2148183: Parameterize puppet for testing Aegir upgrades to get some technical discussion going.

ergonlogic’s picture

Version: 6.x-2.x-dev » 7.x-3.x-dev

New features need to be implemented in Aegir 3.x, then we can consider back-porting to Aegir 2.x.

helmo’s picture

Status: Needs work » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.