-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[server] Allow re-triggering failed Prebuilds #5836
Conversation
4493484
to
4663d1a
Compare
4663d1a
to
8dc1dd4
Compare
🎰 /werft run 👍 started the job as gitpod-build-jx-allow-retriggering-prebuilds.3 |
35d0061
to
4ade98c
Compare
Note to self:
|
4ade98c
to
8a97fd8
Compare
8b5709e
to
00086db
Compare
8454797
to
95220d4
Compare
const p = prebuilds.find(p => p.id === info.id)!; | ||
const r: PrebuildWithStatus = { info, status: p.state }; | ||
if (p.error) { | ||
r.error = p.error; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice!
@gtsiolis, this looks good already, I hope you find some time to check soon. |
/werft run 👍 started the job as gitpod-build-jx-allow-retriggering-prebuilds.24 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @jankeromnes! Took a quick look at the UX changes here. 👀
Left some comment below! 🐈
Curious if this PR really fixes #5771 and #5374. 💭
Approving to unblock merging but holding in case we need to make any further changes.
/hold
{(prebuild?.status === 'aborted' || prebuild?.status === 'timeout' || !!prebuild?.error) | ||
? <button className="flex items-center space-x-2" disabled={isRerunningPrebuild} onClick={rerunPrebuild}> | ||
{isRerunningPrebuild && <img className="h-4 w-4 animate-spin filter brightness-150" src={Spinner} />} | ||
<span>Rerun Prebuild ({prebuild.info.branch})</span> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issue: Including the branch name in the dropdown action could be confusing as most of the times this will overflow and a truncated text will be presented.
Also, since the branch name is the key value in this page (first column field), if we need to repeat this value in the dropdown we may have to reconsider the design of this list layout. ❌
suggestion: What do you think of removing the branch name reference from this dropdown action. We could keep the title attribute if you think it helps. ❓
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, good point, thanks! Would it be cool to:
- Make the dropdown items larger?
- Add a title attribute or tooltip with the full text?
{(!!project && prebuilds.length === 0) && | ||
<button onClick={() => triggerPrebuild(null)} className="ml-2">Run Prebuild</button>} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thought: There's already an issue for adding a minimal empty state for this page in #5022. Ideally, in future iteration a better empty state with an illustration, title, and description would be great.
{(prebuild?.status === 'aborted' || prebuild?.status === 'timeout' || !!prebuild?.error) | ||
? <button className="flex items-center space-x-2" disabled={isRerunningPrebuild} onClick={rerunPrebuild}> | ||
{isRerunningPrebuild && <img className="h-4 w-4 animate-spin filter brightness-150" src={Spinner} />} | ||
<span>Rerun Prebuild ({prebuild.info.branch})</span> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issue: This fails to trigger any prebuild when there's a configuration error:
Error: Request triggerPrebuild failed with message: Invalid gitpod.yml: should be object
question: Ideally, this could trigger a new failed prebuild, right?
thought: Once we add the toast component (#3530) we could surface such errors with a toast notification.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh 😳 I guess you're seeing this error in the console? Could you please provide more details on how you achieved this situation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jankeromnes yes, this is in console.
Steps to reproduce:
- Add a project with an invalid
.gitpod.yml
like https://github.com/issue-reproduce/configuration-error. - Trigger a prebuild for any branch of that project
@@ -159,7 +153,8 @@ export default function () { | |||
<div className="py-3 pl-3"> | |||
<DropDown prefix="Prebuild Status: " contextMenuWidth="w-32" entries={statusFilterEntries()} /> | |||
</div> | |||
<button disabled={!project} onClick={() => triggerPrebuild(null)} className="ml-2">Trigger Prebuild</button> | |||
{(!!project && prebuilds.length === 0) && | |||
<button onClick={() => triggerPrebuild(null)} className="ml-2">Run Prebuild</button>} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issue: The appearing and disappearing button feels a bit flaky, no?
Flaky appearing button ⬇️
Untitled2.mov
Flaky disappearing button ⬇️
Untitled3.mov
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it is flaky. 😞
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😞
@@ -159,7 +153,8 @@ export default function () { | |||
<div className="py-3 pl-3"> | |||
<DropDown prefix="Prebuild Status: " contextMenuWidth="w-32" entries={statusFilterEntries()} /> | |||
</div> | |||
<button disabled={!project} onClick={() => triggerPrebuild(null)} className="ml-2">Trigger Prebuild</button> | |||
{(!!project && prebuilds.length === 0) && | |||
<button onClick={() => triggerPrebuild(null)} className="ml-2">Run Prebuild</button>} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: Also, although I think the run prebuild being always visible is the best approach long term (see #5374 (comment)), instead of hiding this button and causing any confusion should we aim for addign a boring (simple) empty state like the one we have in workspaces for teams with no projects?
Workspaces list for teams with no projects |
---|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Current state of the Run Prebuild
button:
- It requests a new Prebuild for a specific branch (by default, the default branch, but we could make the button branch-specific, or ask with a modal)
- If there is already a successful Prebuild for the requested branch, the backend returns "a successful Prebuild already exists for this branch!" (but we don't show anything in the UI for that case)
- If there is a Prebuild for the requested branch, but it has failed, then the backend will actually trigger a new Prebuild to "try again" (this is new with this PR -- previously it would just say "there is already a (failed) Prebuild for this branch, doing nothing!")
Are you proposing to always allow triggering new Prebuilds? I.e.
- Even if there is a successful Prebuild for a branch (i.e. all the prebuilding work for the latest commit has already been done, and the result is ready to go) we force the creation of a new Prebuild for the same commit?
I don't see the value of this latter change (apart from making our button always enabled) even though it adds a bit more complexity to the backend (i.e. allow forcing the creation of new Prebuilds even if there is already a successful one)
LGTM label has been added. Git tree hash: 2c29e244a1683b632b6dc82c9f58d626f326a0e9
|
[APPROVALNOTIFIER] This PR is APPROVED Approval requirements bypassed by manually added approval. This pull-request has been approved by: gtsiolis Associated issue: #5771 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Many thanks for the review @gtsiolis! 💯 I think a lot of the confusion we have in many Teams & Projects pages stems from the fact that we never actually re-trigger a Prebuild. Instead, we trigger a new Prebuild for a branch. This means that the Eventually, I think this option should only exist for Branches (e.g. Project > Branch > Run Prebuild). That's why I'm really looking forward to #5791 removing the current I'll now fix the merge conflict and address all feedback, in order to get this in rather soon and then iterate on follow-ups. 🙂 |
… with a start date' Fixes: 1) Basic unidirectional replication Should replicate with a start date: Error: Timeout of 2000ms exceeded.
fcfbe64
to
4d954d3
Compare
New changes are detected. LGTM label has been removed. |
Agree! This is still confusing for me sometimes.
Agree! 💯
@jankeromnes DEAL 🤝 |
/meow |
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@jankeromnes can this be merged? We've seen other issues related to preparing/building status of prebuilds/pods, so I'd like to have this on master before going deeper and checking on staging. |
@AlexTugarev Sure! We can merge. Most things can be done as follow-ups. I'm just very unclear on what to do with the infamous I'm not sure the current "flakily disappearing button" is actually better than the previous "mostly not-working button", but maybe this can also be improved as a follow-up? 🤷♂️ |
Carrying over the LGTM, since I've just rebased the PR. /hold cancel |
Description
Related Issue(s)
Fixes #5771
Fixes #5374
How to test
See #5836 (comment)
Release Notes
/uncc