AutoQA tests/Upgradepath

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
m (Fixing the failures)
(Upgrade path constraint is formalized in the added link)
 
(8 intermediate revisions by 2 users not shown)
Line 1: Line 1:
'''Upgradepath''' is a constraint that is not formally described anywhere but it is generally understood as ''the ability to upgrade from Fedora release N to Fedora release N+1''.
+
'''Upgradepath''' is a [[Packaging/NamingGuidelines#Package_Versioning|constraint]] that ensures ''the ability to upgrade from Fedora release N to Fedora release N+1''.
  
In other words no package dependencies may break when the user want to upgrade his/her Fedora. That is achieved by requiring the higher Fedora release to contain at least the same or higher package build versions (in N-V-R sense) than the lower Fedora release.
+
In other words no package dependencies may break when the user wants to upgrade his/her Fedora. That is achieved by requiring the higher Fedora release to contain at least the same or higher package build versions (in N-V-R sense) than the lower Fedora release.
 +
 
 +
[[AutoQA]] executes this test for any update that is proposed in [https://admin.fedoraproject.org/updates/ Bodhi] and reports the result using Bodhi comments at the update page.
  
 
{{admon/note|Does not apply for updates-testing|Upgradepath constraint is currently checked for main and stable updates repositories. It is [https://fedorahosted.org/autoqa/ticket/231 not checked] for updates-testing repository.}}
 
{{admon/note|Does not apply for updates-testing|Upgradepath constraint is currently checked for main and stable updates repositories. It is [https://fedorahosted.org/autoqa/ticket/231 not checked] for updates-testing repository.}}
  
 
= Understanding failures =
 
= Understanding failures =
This is a sample output of the upgradepath test, where <code>selinux-policy-3.9.16-21.fc15</code> was requested to be pushed to <code>f15-updates</code> repository:
+
This is a sample output of the upgradepath test, where <code>duplicity-0.6.14-1.fc14</code> was requested to be pushed to <code>dist-f14-updates</code> repository:
  
 
<pre>
 
<pre>
========================================
+
============================================================
selinux-policy-3.9.16-21.fc15 into dist-f15-updates
+
duplicity-0.6.14-1.fc14 into dist-f14-updates
========================================
+
============================================================
[ OK ] dist-f13
+
Latest package: selinux-policy-3.7.19-10.fc13
+
[ OK ] dist-f13-updates
+
Latest package: selinux-policy-3.7.19-101.fc13
+
 
[ OK ] dist-f14
 
[ OK ] dist-f14
Latest package: selinux-policy-3.9.7-3.fc14
+
Latest package: duplicity-0.6.09-1.fc14.1
[ OK ] dist-f14-updates
+
[INFO] dist-f15 + dist-f15-updates  
Latest package: selinux-policy-3.9.7-40.fc14
+
Latest package: duplicity-0.6.11-2.fc15
[ OK ] dist-f15
+
Latest pending package: duplicity-0.6.14-1.fc15
Latest package: selinux-policy-3.9.16-18.fc15
+
The pending package must be pushed together with the tested package, or else the upgrade path will be broken.
[FAIL] dist-f16
+
[FAIL] f16 + f16-updates
Latest package: selinux-policy-3.9.16-15.fc16
+
Latest package: duplicity-0.6.11-2.fc16
Error: Proposed package must be less than or equal to the latest package
+
Latest pending package: None
 +
[ OK ] f17
 +
Latest package: duplicity-0.7.0-1.fc17
 +
Latest pending package: None
 
RESULT: FAILED
 
RESULT: FAILED
 
</pre>
 
</pre>
  
If you look closely at the '''FAIL''' section, you'll see, that <code>dist-f16</code> (current [[Rawhide]]) contains only <code>selinux-policy-3.9.16-15.fc16</code>, which is lower version than currently proposed <code>selinux-policy-3.9.16-21.fc15</code> for <code>f15-updates</code>. It fails because you wouldn't be able upgrade from F15 to F16 correctly if the proposed update had been pushed.
+
The '''OK''' sections denote repositories where upgradepath constraint would be fulfilled after pushing the proposed update. For example it would be possible to upgrade from <code>dist-f14</code>, because it contains lower version of <code>duplicity</code> package. And it would be also possible to (directly) upgrade to <code>f17</code> repository, because it contains higher version of <code>duplicity</code> package.
 +
 
 +
The '''INFO''' section is almost the same as '''OK''', it just means we provided some information you should read. In this case the upgradepath constraint will be fulfilled only if the build proposed for <code>dist-f15-updates</code> is pushed at the same time as our proposed build for <code>dist-f14-updates</code>. This happens quite often, because package maintainers use to propose new package builds for several Fedora releases at once. It is good to know though that if you notice that these pending builds were not pushed simultaneously you should contact [[ReleaseEngineering|RelEng team]] and ask them to fix it, otherwise your package will have its upgrade path broken.
 +
 
 +
If you look closely at the '''FAIL''' section, you'll see, that the union of <code>f16</code> and <code>f16-updates</code> repositories contains only <code>duplicity-0.6.11-2.fc16</code>, which is lower version than currently proposed <code>duplicity-0.6.14-1.fc14</code> for <code>dist-f14-updates</code>. It fails because you wouldn't be able upgrade from F14 (through F15) to F16 correctly if the proposed update had been pushed.
  
 
== Upgradepath test algorithm ==
 
== Upgradepath test algorithm ==
The formal description of the algorithm AutoQA uses for checking upgradepath constraint is here:
+
The formal description of the algorithm [[AutoQA]] uses for checking upgradepath constraint is here:
 
<pre>
 
<pre>
 
== Pushing to main repository ==
 
== Pushing to main repository ==
Line 42: Line 47:
 
   1. PKG in F(lower)-main <= PKG to push
 
   1. PKG in F(lower)-main <= PKG to push
 
   2. PKG in F(lower)-updates <= PKG to push
 
   2. PKG in F(lower)-updates <= PKG to push
   3. PKG in F(higher)-main union F(higher)-updates => PKG to push
+
   3. PKG in F(higher)-main union F(higher)-updates union F(higher)-updates-pending => PKG to push
  
 
Note: If PKG doesn't exist in REPO, it also satisfies any condition
 
Note: If PKG doesn't exist in REPO, it also satisfies any condition
Line 48: Line 53:
  
 
= Fixing the failures =
 
= Fixing the failures =
The general guidelines are these:
+
The general guidelines for resolving failures include:
<ul>
+
<ol>
<li>'''Push first to the highest Fedora release and only then to a lower one.'''<br/>
+
You can of course propose your update for all supported Fedora releases at once, but upgradepath test will not pass for any Fedora release until it has been pushed to all higher Fedora releases.</li>
+
 
<li>'''Consult packaging guidelines when in doubt how package build versions are compared.'''<br/>
 
<li>'''Consult packaging guidelines when in doubt how package build versions are compared.'''<br/>
 
See especially the [[Packaging:NamingGuidelines|Naming guidelines]].</li>
 
See especially the [[Packaging:NamingGuidelines|Naming guidelines]].</li>
 +
<li>'''Be conservative about karma auto-push when doing update for multiple releases.'''<br/>
 +
If you enable karma auto-push for a proposed update for several Fedora releases, it can easily happen that a lower-Fedora-release update will be auto-pushed sooner than a higher-Fedora-release update. Then you will receive failures from upgradepath. The best approach is to enable karma auto-push just for the highest Fedora release and handle the rest manually (push lower release update only after a higher release updates are pushed/requested).</li>
 
<li>'''If you want to push a fix for an older Fedora but not for a newer one, do a proper minor release bump.'''<br/>
 
<li>'''If you want to push a fix for an older Fedora but not for a newer one, do a proper minor release bump.'''<br/>
 
Read [[Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches|Minor release bumps for old branches]] to learn more.</li>
 
Read [[Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches|Minor release bumps for old branches]] to learn more.</li>
</ul>
+
</ol>
  
 
= Further help =
 
= Further help =

Latest revision as of 15:30, 17 November 2011

Upgradepath is a constraint that ensures the ability to upgrade from Fedora release N to Fedora release N+1.

In other words no package dependencies may break when the user wants to upgrade his/her Fedora. That is achieved by requiring the higher Fedora release to contain at least the same or higher package build versions (in N-V-R sense) than the lower Fedora release.

AutoQA executes this test for any update that is proposed in Bodhi and reports the result using Bodhi comments at the update page.

Note.png
Does not apply for updates-testing
Upgradepath constraint is currently checked for main and stable updates repositories. It is not checked for updates-testing repository.

Contents

[edit] Understanding failures

This is a sample output of the upgradepath test, where duplicity-0.6.14-1.fc14 was requested to be pushed to dist-f14-updates repository:

============================================================
duplicity-0.6.14-1.fc14 into dist-f14-updates
============================================================
[ OK ] dist-f14
	Latest package: duplicity-0.6.09-1.fc14.1
[INFO] dist-f15 + dist-f15-updates 
	Latest package: duplicity-0.6.11-2.fc15
	Latest pending package: duplicity-0.6.14-1.fc15
	The pending package must be pushed together with the tested package, or else the upgrade path will be broken. 
[FAIL] f16 + f16-updates
	Latest package: duplicity-0.6.11-2.fc16
	Latest pending package: None
[ OK ] f17
	Latest package: duplicity-0.7.0-1.fc17
	Latest pending package: None
RESULT: FAILED

The OK sections denote repositories where upgradepath constraint would be fulfilled after pushing the proposed update. For example it would be possible to upgrade from dist-f14, because it contains lower version of duplicity package. And it would be also possible to (directly) upgrade to f17 repository, because it contains higher version of duplicity package.

The INFO section is almost the same as OK, it just means we provided some information you should read. In this case the upgradepath constraint will be fulfilled only if the build proposed for dist-f15-updates is pushed at the same time as our proposed build for dist-f14-updates. This happens quite often, because package maintainers use to propose new package builds for several Fedora releases at once. It is good to know though that if you notice that these pending builds were not pushed simultaneously you should contact RelEng team and ask them to fix it, otherwise your package will have its upgrade path broken.

If you look closely at the FAIL section, you'll see, that the union of f16 and f16-updates repositories contains only duplicity-0.6.11-2.fc16, which is lower version than currently proposed duplicity-0.6.14-1.fc14 for dist-f14-updates. It fails because you wouldn't be able upgrade from F14 (through F15) to F16 correctly if the proposed update had been pushed.

[edit] Upgradepath test algorithm

The formal description of the algorithm AutoQA uses for checking upgradepath constraint is here:

== Pushing to main repository ==
Pushing PKG to F(N)-main means:
  1. PKG in F(lower)-main <= PKG to push
  2. PKG in F(higher)-main >= PKG to push

== Pushing to updates repository ==
Pushing PKG to F(N)-updates means:
  1. PKG in F(lower)-main <= PKG to push
  2. PKG in F(lower)-updates <= PKG to push
  3. PKG in F(higher)-main union F(higher)-updates union F(higher)-updates-pending => PKG to push

Note: If PKG doesn't exist in REPO, it also satisfies any condition

[edit] Fixing the failures

The general guidelines for resolving failures include:

  1. Consult packaging guidelines when in doubt how package build versions are compared.
    See especially the Naming guidelines.
  2. Be conservative about karma auto-push when doing update for multiple releases.
    If you enable karma auto-push for a proposed update for several Fedora releases, it can easily happen that a lower-Fedora-release update will be auto-pushed sooner than a higher-Fedora-release update. Then you will receive failures from upgradepath. The best approach is to enable karma auto-push just for the highest Fedora release and handle the rest manually (push lower release update only after a higher release updates are pushed/requested).
  3. If you want to push a fix for an older Fedora but not for a newer one, do a proper minor release bump.
    Read Minor release bumps for old branches to learn more.

[edit] Further help

If you still don't understand why your update failed the test, or if you think there's something wrong in our test or its documentation, or if you have any other suggestions, please contact us.