release procedure issues

[sdarwin]

During this release, the download archive links didn't import. Tried "Import Releases" again. That will import all releases. There were varying results:

• On production:

This error

  418 psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "versions_versionfile_checksum_key"
  419 DETAIL:  Key (checksum)=(7faf60c4cb12ee90270e41716cf3735a8739016d7346983ce9f5e899e510b26d) already exists.

That checksum corresponded to the 1.88.0 beta release, the 7z download. So when it attempts to import all releases again, there was this conflict. This is unexpected since "Import Releases" has worked in the past. Any time you re-import all releases, it should skip conflicts.

Manually ran "manage.py import_archives_release_data" and that went through.

• On staging:

Tried "Import Releases" again. It imported 1.88.0. The download archive links didn't import. There was no indication "import_archives_release_data" was called, even though it is supposed to be.

Manually ran "manage.py import_archives_release_data" and that went through.

Next ... on both Production and Staging ... the libraries still had not imported.

Manually ran "manage.py import_library_versions" and that went through.

An explanation may be, for example, that the above mentioned checksum crash disrupted further steps, and so it never reached "import_library_versions". At least on production, that is possible. On staging, it was as if it just did not proceed from "Import Releases" to those other steps.

Greg reports that he ran "import releases" locally and it was successful for all steps, so uncertain.

[sdarwin]

Something else to investigate in connection with duplicate key values.
While it may be extremely rare, it does not seem impossible that a beta and an official release are based on the same code.
Notice that renaming a file doesn't modify the SHA:

$ sha256sum boost_1_88_0.tar.gz
3621533e820dcab1e8012afd583c0c73cf0f77694952b81352bf38c1488f9cb4  boost_1_88_0.tar.gz
$ cp boost_1_88_0.tar.gz boost_1_88_0_b1.tar.gz  
$ sha256sum boost_1_88_0_b1.tar.gz
3621533e820dcab1e8012afd583c0c73cf0f77694952b81352bf38c1488f9cb4  boost_1_88_0_b1.tar.gz
$ 

How about permitting the same checksum?
Even if this occurs less than 1% of the time, or never, it might happen.
Both the beta and the official release are created by copying a "daily" snapshot, and renaming it.
They don't contain ".git" subdirs.
A release could conceivably be created by copying a beta, and renaming it, and that would have the same SHA. Which is not inherently wrong.

Edit:

Realistically, this might not ever happen.
There will always be something new added between a beta and an official release.
Nevertheless, it's appealing to be logical...
If two people can have the same middle name, why not allow such an event in the DB. And the same in this case. why not allow it.
Although I may be missing something if decisions are based on the checksum in other db tables.