You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Improve how we surface prebuild information, including status, duration and actionable errors to users
The main focus of this epic is on surfacing information about the "trigger" of a prebuild, and what consequence that trigger had.
Context
In the past we focussed on increasing prebuild reliability technically:
But the perceived instability - and source of a big chunk of inbound user requests - is caused by uncertainty about if, how and why not a prebuild was triggered by some user action. This also affects Self-Hosted as the question "is my SCM correctly setup" is a frequently brought up during/after installation and can trivially answered from such a "prebuild trigger" view.
Also, this uncertainty will only increase when it comes to introducing more options for configuring prebuilds in the context of Usage Based Pricing.
Value
Clear and understandable prebuild statuses will increase trust in Prebuilds and as result in Gitpod as a product. It will enable users to optimize their prebuilds to be able to get the most out of Gitpod.
Acceptance Criteria
Prebuild UI (and APIs) communicate prebuild information consistently
Uh oh!
There was an error while loading. Please reload this page.
Summary
Improve how we surface prebuild information, including status, duration and actionable errors to users
The main focus of this epic is on surfacing information about the "trigger" of a prebuild, and what consequence that trigger had.
Context
In the past we focussed on increasing prebuild reliability technically:
But the perceived instability - and source of a big chunk of inbound user requests - is caused by uncertainty about if, how and why not a prebuild was triggered by some user action. This also affects Self-Hosted as the question "is my SCM correctly setup" is a frequently brought up during/after installation and can trivially answered from such a "prebuild trigger" view.
Also, this uncertainty will only increase when it comes to introducing more options for configuring prebuilds in the context of Usage Based Pricing.
Value
Clear and understandable prebuild statuses will increase trust in Prebuilds and as result in Gitpod as a product. It will enable users to optimize their prebuilds to be able to get the most out of Gitpod.
Acceptance Criteria
Growth Area
Persona(s)
No response
Hypothesis
No response
In scope
No response
Out of scope
No response
Complexities
No response
Press release
No response
Issues
triggers UI:
Show prebuild configuration state on the project prebuilds page #7010Display "prebuild trigger" in the UI #10765observability:
[server] add a metric for received webhook events #9170The text was updated successfully, but these errors were encountered: