Skip to content

fix EPINIO-716: show Rebuild for failed builds with reusable source - #638

Open
psanghvi17 wants to merge 2 commits into
1.14.2from
feat/retry-failed-builds
Open

fix EPINIO-716: show Rebuild for failed builds with reusable source#638
psanghvi17 wants to merge 2 commits into
1.14.2from
feat/retry-failed-builds

Conversation

@psanghvi17

Copy link
Copy Markdown
Contributor

Summary

Fixes #EPINIO-716

When a build fails, the applications table should show an error state (not created), and users should be able to retry when source is still available. This UI change enables Rebuild when git or a stored blobuid is present, and uses async deploy for never-deployed / failed first pushes.

Depends on API PR: epinio/epinio#3100

Occurred changes and/or fixed issues

  • Restage/Rebuild action is enabled via canRetryBuild (git origin or blobuid), and disabled for container-image apps and while staging is active.
  • For apps with no deployment yet (failed first build), restage now runs async deploy with stored blobuid / git origin instead of requiring a prior successful deployment.stage_id.
  • For already-deployed apps, existing restage (+ optional restart when running) behavior is preserved.
  • App TypeScript types expose blobuid and stagingstatus so the model can drive retry eligibility from the API.

Technical notes summary

  • canRetryBuild: container URL → false; otherwise true when origin.git or blobuid is present (covers SeaweedFS/S3 reuse for folder/archive uploads).
  • retryDeployOrigin normalizes origin for async deploy without wiping source metadata when Kind is missing.
  • Failed/never-deployed path clears async deploy cache and calls waitAsyncDeployPhase; deployed path keeps stage() + waitForStaging.
  • Error growl now surfaces the thrown message when rebuild is not possible.

Areas or cases that should be tested

Browser used locally: Chromium/Chrome (reviewer please use Firefox or Edge).

  1. Fail a git app build → applications table shows error (with API PR) → Rebuild is enabled → Rebuild restages/deploys successfully.
  2. Fail a folder/archive upload build while blob remains in storage → Rebuild enabled → retry succeeds using blobuid.
  3. Container-image app: Rebuild/restage remains disabled.
  4. While status/staging is active: Rebuild disabled.
  5. Already-running app with git/blob source: Rebuild/restage still works (restage path, not async-first-push path).
  6. App with neither git nor blobuid: Rebuild disabled / clear error if attempted.
  7. Applications table status badge/colors for error vs created vs building vs running.
  8. Staging logs still open after a successful retry when stage_id is present.

Areas which could experience regressions

  • Application row action menu (Restage/Rebuild enablement rules).
  • Async deploy / first-push flows that share waitAsyncDeployPhase / ensureAsyncDeployStarted.
  • Restage + restart behavior for running apps.
  • Origin handling on redeploy (gitconfig / path / archive metadata must not be wiped).
  • Any view that assumes restage only appears when deployment.stage_id exists.

Add canRetryBuild when git or blobuid is available, hide it for container
image apps and while staging. restage uses async deploy when no deployment
exists so failed builds can retry without a prior successful stage. Expose
blobuid and stagingstatus on app types.
Show a Deploying badge instead of Unknown after staging succeeds, and keep restage disabled while deploy is still in progress.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant