For the record, the current db schema is:

mysql> describe afe_stable_versions;
+---------+--------------+------+-----+---------+----------------+
| Field   | Type         | Null | Key | Default | Extra          |
+---------+--------------+------+-----+---------+----------------+
| id      | int(11)      | NO   | PRI | NULL    | auto_increment |
| board   | varchar(255) | NO   | UNI | NULL    |                |
| version | varchar(255) | NO   |     | NULL    |                |
+---------+--------------+------+-----+---------+----------------+
3 rows in set (0.00 sec)

https://chromium-review.googlesource.com/c/chromiumos/third_party/autotest/+/749057

Open question: what exactly is the expected format of the string we want in image_path column. And is |image_path| a good name?

My strawman: image_path should look like:

gs://chromeos-image-archive/daisy-release/R64-10089.0.0/

Copying my comment from the CL: Just getting to the image's topdir may not be enough because we have various kinds of images:

There are multiple types of stable versions, and the image that we want is dependent on that: 

- cros-version: ChromeOS image, GS path;
- android-version: Android image, I'm not sure where we get this image from (Is this also _some_ GS bucket);
- 2 types if firmware versions: ChromeOS firmware blobs, paths are similar to chromeos-version, but the exact artifact given the folder is different.

I'd say that this new column should be a link to the _final artifact_ that one wants. So, not to the directory containing all image files for a given chrome os version, but a path to the image itself.

And in that case, let's name this artifact_path or something generic that includes the firmware blobs in it.

jrbarnette@ should confirm that I'm not oversimplifying.

sgtm. artifact_url then?

sgtm
FTR, this is where the build name --> URL mapping happens (sort of): https://cs.corp.google.com/chromeos_public/src/third_party/autotest/files/client/common_lib/cros/dev_server.py?l=2387

<rant>
You're going to have a hard time chasing archive_url
I believe it comes from variuos sources. And it standard autotest style, it gets overwritten multiple times, and it's not clear which ones matter... etc.
A quick look didn't tell me how I'd use a full URL instead of a build name for the repair flow.
</rant>

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/c0ea883be96eab2c068d9af3fffe539c0234a964

commit c0ea883be96eab2c068d9af3fffe539c0234a964
Author: Aviv Keshet <akeshet@chromium.org>
Date: Wed Nov 08 23:10:12 2017

autotest: add archive_url column to afe_stable_versions

BUG=chromium:780568
TEST=None

Change-Id: I5036d0bd044f6b0dd095720e838c07fd150d884d
Reviewed-on: https://chromium-review.googlesource.com/749057
Commit-Ready: Aviv Keshet <akeshet@chromium.org>
Tested-by: Aviv Keshet <akeshet@chromium.org>
Reviewed-by: Prathmesh Prabhu <pprabhu@chromium.org>

[add] https://crrev.com/c0ea883be96eab2c068d9af3fffe539c0234a964/frontend/migrations/121_update_afe_stable_versions_table_add_archive_url.py

I've lost the thread of this. Richard is this still necessary, or have it been accomplished by other means?

> I've lost the thread of this. Richard is this still necessary,
> or have it been accomplished by other means?

The underlying sentiment is roughly a good idea.  It's not clear
to me that changing the database schema is necessary (if it's
actually unnecessary, it may or may not be advisable; if advisable
the change actually applied may or may not be the best option).  My
plans for addressing this problem didn't involve changing the database
schema.