Invenio package update

[ItIsJordan]

This PR tackles the upgrading of the Invenio packages, which is work that can now be completed and merged following PR #964 to upgrade to SQLAlchemy 2.0.

No code changes were required, but there are a number of manual steps that must be undertaken (to be commented) as there are some problems with migrations across the Invenio packages. For example, see the Alembic migrations problems discussion within the Invenio product-rdm repo.

Partially addresses #848.
Closes #957.
Closes #967.
Closes #1013.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.91%. Comparing base (8fa68fb) to head (88fc891).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1014   +/-   ##
=======================================
  Coverage   86.91%   86.91%           
=======================================
  Files          59       59           
  Lines        5823     5823           
=======================================
  Hits         5061     5061           
  Misses        762      762           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[coveralls]

Coverage Report for CI Build 34332544329

Coverage remained the same at 86.914%

Details

• Coverage remained the same as the base build.
• Patch coverage: No coverable lines changed in this PR.
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	5823
Covered Lines:	5061
Line Coverage:	86.91%
Coverage Strength:	0.87 hits per line

---

💛 - Coveralls

[GraemeWatt]

The latest Invenio packages have some database changes, so a migration is needed by running hepdata alembic upgrade. Before running this command, the alembic_version database table should look like this:

hepdata=> select * from alembic_version order by version_num;
 version_num
--------------
 07fb52561c5c
 41157f1933d6
 6ec5ce377ca3
 999c62899c20
 aaa265b0afa6
(5 rows)

This matches the production database. A couple of issues were encountered that needed to be worked around.

1. Error message psycopg2.errors.DuplicateObject: constraint "fk_access_actionsroles_role_id_accounts_role" for relation "access_actionsroles" already exists from invenio_access/alembic/f9843093f686_change_fk_accountsrole_to_string_upgrade.py. Inspecting the database (both local and production), it appears that the upgrade is not needed, e.g. role_id in the access_actionsroles table already has type character varying(80), therefore we can add the revision identifier manually to skip the upgrade:

hepdata=> insert into alembic_version values ('f9843093f686');
INSERT 0 1

2. Error message psycopg2.errors.UndefinedTable: relation "records_metadata_version" does not exist from invenio_records/alembic/428b919be0ea_alter_column_from_json_to_jsonb_for_version.py. The records_metadata_version (and transaction) database tables are not created unless using the versioning support provided by SQLAlchemy-Continuum, but this is disabled using the DB_VERSIONING = False option of invenio-db.The identifier 07fb52561c5c implies that the recipe 07fb52561c5c_alter_column_from_json_to_jsonb.py should have been applied, but the type of the json field in the records_metadata table is json not jsonb. We can comment out the parts of the upgrade recipes (installed locally in venv/lib/python3.14/site-packages/ or deployed in /usr/local/lib/python3.14/site-packages/) that modify the records_metadata_version table, i.e. parts of invenio_records/alembic/428b919be0ea_alter_column_from_json_to_jsonb_for_version.py and invenio_records/alembic/66db9c49c699_change_datetime_types.py. Then set the revision identifier:

hepdata=> update alembic_version set version_num='862037093962' where version_num='07fb52561c5c';
UPDATE 1

Alternatively, to avoid modifying the Invenio .py files, the database modifications contained in the relevant Alembic recipes could instead be made manually, i.e.

hepdata=> alter table records_metadata alter column json type jsonb;
ALTER TABLE
hepdata=> alter table records_metadata alter column created type timestamp with time zone;
ALTER TABLE
hepdata=> alter table records_metadata alter column updated type timestamp with time zone;
ALTER TABLE
hepdata=> update alembic_version set version_num='66db9c49c699' where version_num='07fb52561c5c';
UPDATE 1

---

After making these changes, the hepdata alembic upgrade command runs successfully, and my updated alembic_version table now looks like this:

hepdata=> select * from alembic_version order by version_num;
 version_num
--------------
 23e196599f9f
 41157f1933d6
 66db9c49c699
 734dbec0f3f8
 edf0c0907f40
 f9843093f686
(6 rows)

I made another check where I dropped the alembic_version table from the database, then recreated it with hepdata alembic stamp and the recreated version_num entries matched those above. I'll log an issue in the invenio-records repo to note that the config option DB_VERSIONING = False is not properly supported by the Alembic recipes, which assume existence of the records_metadata_version (and transaction) database tables that are only created if DB_VERSIONING = True (the default).

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.