Files

T

Deploy staging to test server / deploy (push) Successful in 6m34s

Details

fix: complete self-hosted staging identity integration

Align staging deployment, authentication, and admin access with the self-hosted identity boundary, including regression coverage and deployment diagnostics.

2026-07-30 14:54:46 +08:00

1.7 KiB

Raw Blame History

Debug Session: npm-integrity-failure

Status: [OPEN] Started: 2026-07-29

Symptom

Gitea staging Web image build fails during npm ci for server-only@0.0.1 with EINTEGRITY. The downloaded 477-byte tarball digest differs from package-lock.json.

Constraints

Do not modify business logic during evidence collection.
Do not expose registry credentials or application secrets.
Preserve the current staging deployment until a verified image and migration are ready.

Hypotheses

The lockfile integrity for server-only@0.0.1 is incorrect.
The Runner network path receives corrupted or substituted registry bytes.
BuildKit/npm cache contains a corrupted tarball and retries reuse it.
A proxy or registry override affects the Runner despite the npmjs URL in logs.
The upstream tarball changed while registry metadata and lockfile diverged.

Evidence

package-lock.json expects server-only@0.0.1 integrity ending in GNSg==.
The failed Gitea task downloaded 477 bytes and computed integrity ending in iswNA== twice.
Current registry metadata reports integrity ending in iswNA==.
A direct download from registry.npmjs.org on xiaoxin is 477 bytes and computes the same integrity ending in iswNA==.
A clean Docker Hub probe was blocked by an unrelated Docker Hub timeout.

Conclusion: H1/H5 confirmed. The locked integrity is stale relative to the current tarball. H2/H3/H4 are rejected by the consistent direct-download and metadata evidence.

Fix

Update only the stale server-only@0.0.1 integrity entry in package-lock.json to the digest proven by registry metadata and direct download.

Verification

Pending post-fix workflow.

1.7 KiB Raw Blame History