archive publisher needs to learn how to publish from a test-rebuild archive copy

Bug #520520 reported by LaMont Jones
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Fix Released
High
Julian Edwards

Bug Description

Now that we can create a copy archive and not have it show up, well... we need to put a publisher instance on another machine that specifically _just_ publishes exactly that copy archive, and does it in a way that doesn't confuse the mainline archive publisher.

This will allow us to publish the rebuilt archive for a second-round testing, so that we can find things like "when rebuilt from current source, gcc doesn't successfully build packages any more" or "when we rebuilt libc6, everything broke"

thanks,
lamont

Related branches

Changed in soyuz:
status: New → Triaged
importance: Undecided → High
tags: added: soyuz-publish
Revision history for this message
Julian Edwards (julian-edwards) wrote :

Steps to fixing:

* IArchive.archive_url:
  needs to cope with ArchivePurpose.COPY

* lib/lp/soyuz/scripts/publishdistro.py
  New option --copy-archives
  copy archives still must use a-f, change the logic at the bottom of the file

* lp/archivepublisher/config.py - getPubConfig
  needs to cope with ArchivePurpose.COPY

If the publishing location needs to be different, then a new canonical.config block is required for copy archives.

Revision history for this message
William Grant (wgrant) wrote :

You also need to fix process-accepted.py.

Revision history for this message
Julian Edwards (julian-edwards) wrote :

I don't think you do - copy archives don't go through the accepted state in the queue.

Changed in soyuz:
milestone: none → 10.02
assignee: nobody → Julian Edwards (julian-edwards)
status: Triaged → In Progress
Revision history for this message
William Grant (wgrant) wrote :

realiseUpload is all that can cause a binary to move from ACCEPTED to DONE, and for non-source uploads that's only called by process-accepted.py. https://edge.launchpad.net/api/beta/ubuntu/+archive/test-rebuild-20090513/?ws.op=getPublishedBinaries suggests that there are no binary publishing records.

Revision history for this message
Julian Edwards (julian-edwards) wrote :

Right - I'd forgotten about the binaries.

Revision history for this message
Julian Edwards (julian-edwards) wrote :

We will build in 2 phases, each with different dependency requirements:

phase1: depends phase1, main_archive
phase2: depends phase2, phase1, main_archive

The +admin form on the copy archive page can then set up to include itself and other archives (phase1, phase2 in this case). archivedependencies.py/get_sources_list_for_building() needs altering so that it puts these dependencies in the right order.

This means we need to publish rebuilds in real-time, so will need a cron job on mcmurdo (where they're being published). We also need a new config item to complement base_url, e.g. copy_archive_base_url)

When fixing IArchive.archive_url, it should make sure the copy archive name is in the path so there can be more than one of them on the same machine.

Revision history for this message
Diogo Matsubara (matsubara) wrote : Bug fixed by a commit
Changed in soyuz:
status: In Progress → Fix Committed
Changed in soyuz:
status: Fix Committed → In Progress
Revision history for this message
Diogo Matsubara (matsubara) wrote :
Changed in soyuz:
status: In Progress → Fix Committed
Changed in soyuz:
status: Fix Committed → In Progress
Revision history for this message
Julian Edwards (julian-edwards) wrote :

We also need to add a UI change to enable someone to change the "publish" flag on the archive. We can put this on the +edit form.

Revision history for this message
Diogo Matsubara (matsubara) wrote :
Changed in soyuz:
status: In Progress → Fix Committed
Revision history for this message
Julian Edwards (julian-edwards) wrote :

The binaries that get uploaded go right into the NEW queue - they need to be auto-accepted for COPY archives. More changes to the upload processor needed.

Changed in soyuz:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.