At the end of it all though, the final production check end-to-end for mercurial origin should go green.
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Migrated | gitlab-migration | T3338 Load the archived bitbucket mercurial repositories | ||
| Migrated | gitlab-migration | T3418 Decide a consistent policy on having multiple archived objects for the same extid | ||
| Migrated | gitlab-migration | T3448 production: Deploy swh.loader.mercurial v2.1.0 |
At the end of it all though, the final production check end-to-end for mercurial origin should go green.
It's working but the check does not pass green [1]. As far as i could tell, the unsuccessful
event [1] is seen as failure by the check.
Unsuccessful now because one load was successful first (through swh loader run on one
worker because no logs were seen and i grew bored looking for it).
[1] As can be seen by the extid_version set to 1. This means the hg loader did its job
(around ~1100 extids for the tested origin). There are more here because the sourceforge
mercurial origins also started.
17:39:06 softwareheritage@belvedere:5432=> select now(), extid_type, extid_version, count(*) from extid group by extid_type, extid_version order by extid_version desc; +-------------------------------+-------------------------+---------------+----------+ | now | extid_type | extid_version | count | +-------------------------------+-------------------------+---------------+----------+ | 2021-07-29 15:38:42.289853+00 | hg-nodeid | 1 | 32774 | | 2021-07-29 15:38:42.289853+00 | cran-sha256 | 0 | 30131 | | 2021-07-29 15:38:42.289853+00 | dsc-sha256 | 0 | 67753 | | 2021-07-29 15:38:42.289853+00 | hg-nodeid | 0 | 19587036 | | 2021-07-29 15:38:42.289853+00 | npm-archive-sha1 | 0 | 19461834 | | 2021-07-29 15:38:42.289853+00 | package-manifest-sha256 | 0 | 8391 | | 2021-07-29 15:38:42.289853+00 | pypi-archive-sha256 | 0 | 2519490 | | 2021-07-29 15:38:42.289853+00 | subresource-integrity | 0 | 68712 | +-------------------------------+-------------------------+---------------+----------+ (8 rows) Time: 19726.983 ms (00:19.727)
It's working but the check does not pass green [1]. As far as i could tell, the unsuccessful
event [1] is seen as failure by the check.
That was not what i hypothesized.
There is a glitch somewhere which looks like a race condition in the status updates
between the scheduler db and the swh-web db.
But let's keep that for another time.
It's finally back to green as initially expected [1]
18:16 <+swhbot> icinga RECOVERY: service production Check save-code-now hgview with type hg end-to-end on pergamon.softwareheritage.org is OK: SAVECODENOW OK - Save code now request for origin ('hg', 'https://foss.heptapod.net/mercurial/hgview') took 75.73s and succeeded.Closing now.