Fix repo setup for Branched update tests (I hope)

Branched update tests are all failing because the baseurl in
fedora.repo is incorrect for Branched. This is a rather hacky
fix for this problem. It relies on the scheduler setting the
DEVELOPMENT variable when the update is for Branched (I named
the variable DEVELOPMENT rather than BRANCHED to be more
future-proof).

Alternative options I rejected were:

i) stick with MM links
ii) do something 'clever' to retrieve the URLs from MM

Rejected i) because the timing problem where the infra repo gets
updated before MM has the updated repodata checksums is just too
much of a problem; whenever that happens, dnf will refuse to use
the metadata from the infra repo and go pull it from an external
mirror, which can wind up timing out.

Rejected ii) because it seemed too fancy and not really any more
robust than just doing this and adapting it if Things Change In
Future (TM).

VARIABLES.md

@@ -88,6 +88,7 @@ These variables should be set when tests are scheduled (when running `isos post`
 | `ADVISORY` | A Bodhi update ID. If set, the 'update testing' flow will be used: post-install tests will be run with the packages from the update, starting from the stable release base disk images |
 | `DISTRI` | contains distribution name (should be same as in WebUI, probably `fedora`) |
 | `VERSION` | contains version of distribution |
+| `DEVELOPMENT` | set for update tests if the update is for a development release (not a stable release) |
 | `FLAVOR` | indicates what type of distribution is used. Three Pungi properties, joined with `-`: `variant`, `type`, and `format`. e.g.: `Server-dvd-iso`. Special value `universal` is used to schedule the group of tests that should be run once each per arch per compose, against the 'best' available ISO |
 | `ARCH` | is set to architecture that will be used (`x86_64`, `i686`) |
 | `BUILD` | contains Pungi compose_id (something like `Fedora-24-20160121.n.3`) |

lib/utils.pm

@@ -304,10 +304,20 @@ sub _repo_setup_updates {
     # Appropriate repo setup steps for testing a Bodhi update
     # Check if we already ran, bail if so
     return unless script_run "test -f /etc/yum.repos.d/advisory.repo";
-    # Use baseurl not metalink so we don't wind up timing out getting
+    # Use baseurl not metalink so we don't hit the timing issue where
-    # metadata from a slow source...baseurl will always give us dl
+    # the infra repo is updated but mirrormanager metadata checksums
-    # in infra
+    # have not been updated, and the infra repo is rejected as its
+    # metadata checksum isn't known to MM
     assert_script_run "sed -i -e 's,^metalink,#metalink,g' -e 's,^#baseurl,baseurl,g' /etc/yum.repos.d/fedora*.repo";
+    # Fix URL for fedora.repo if this is a development release
+    # This is rather icky, but I can't think of any better way, really
+    # The problem here is that the 'baseurl' line in fedora.repo is
+    # always left as the correct URL for a *stable* release, we don't
+    # change it to the URL for a Branched release while the release is
+    # Branched, as it's too much annoying package work
+    if (get_var("DEVELOPMENT")) {
+        assert_script_run "sed -i -e 's,/releases/,/development/,g' /etc/yum.repos.d/fedora.repo";
+    }
     # Set up an additional repo containing the update packages. We do
     # this rather than simply running a one-time update because it may
     # be the case that a package from the update isn't installed *now*