fix(actions): preserve created_unix when re-uploading an expired artifact

[bircni]

When a workflow re-uploads an artifact whose previous content had already
expired (and whose storage blob was removed by the cleanup job), CreateArtifact
revives the existing DB row as a fresh pending upload. This PR fixes two problems
in that path and adds test coverage.

1. Revive path resets status/storage but leaves stale content pointers

Previously, a matching row in a terminal state (Expired / PendingDeletion /
Deleted) was "revived" by only bumping expired_unix. That left the row stuck
in its terminal status while still pointing at a StoragePath/FileSize that no
longer correspond to any content. A re-upload now reinitializes the row in place
as a brand-new UploadPending record (the unique index on
run_id/run_attempt_id/name/path requires updating the existing row rather than
inserting a second one).

2. created_unix was being clobbered on every re-upload

The revive path returned a struct whose CreatedUnix was 0. Both callers hand
that returned struct straight to UpdateArtifactByID, which uses AllCols() —
so the zero value overwrote the row's original creation timestamp. The fix
carries existing.CreatedUnix onto the returned struct so the subsequent
AllCols() update preserves it.

Why

Re-running a job after its artifact expired is a normal case. Without this fix
the artifact row keeps a dead status and stale storage pointers, and its
created_unix gets reset to "now" on every re-upload.

[lunny]

When and why a re-upload was allowed?

[bircni]

When and why a re-upload was allowed?

On a rerun of a job...

[lunny]

When and why a re-upload was allowed?

On a rerun of a job...

Wouldn’t there be a job attempt ID to prevent them from overriding each other?

[bircni]

When and why a re-upload was allowed?

On a rerun of a job...

Wouldn’t there be a job attempt ID to prevent them from overriding each other?

Reruns don't override each other — cloneRunJobForAttempt assigns a new RunAttemptID, and the unique key includes run_attempt_id, so each attempt gets its own row. The re-upload this fixes is within the same run+attempt: upload-artifact@v4 with overwrite: true deletes the artifact (SetArtifactNeedDeleteByRunAttempt → PendingDeletion) and then re-creates the same name/path. The old code revived that dead row by only bumping expired_unix, leaving it in a terminal status pointing at a deleted blob. IsTerminal() catches that and reinitializes it as a fresh pending upload instead.

[Zettat123]

Actually I don't see the two problems on main branch.

1. Revive path resets status/storage but leaves stale content pointers

The stale file can be deleted by

gitea/routers/api/actions/artifacts_chunks.go

Lines 379 to 386 in b09920a

	// save storage path to artifact
	log.Debug("[artifact] merge chunks to artifact: %d, %s, old:%s", artifact.ID, storagePath, artifact.StoragePath)
	// if artifact is already uploaded, delete the old file
	if artifact.StoragePath != "" {
	if err := st.Delete(artifact.StoragePath); err != nil {
	log.Warn("Error deleting old artifact: %s, %v", artifact.StoragePath, err)
	}
	}

2. created_unix was being clobbered on every re-upload

artifact returned by getArtifactByNameAndPath should hava a non-empty CreatedUnix and .AllCols().Update() doesn't update the xorm:"created" field.