Open jankeromnes opened 2 years ago
In the database, we can see that prebuild abcd
has:
state: "available"
error: "headless task failed: exit status 255"
Thus, I suspect that Gitpod returns this prebuild as "already completed successfully" just by looking at the state
, whereas it should probably look at the error
field as well.
Another data point -- when opening the Prebuild page, it seems to show inconsistent status and logs between reloads:
@jankeromnes Let's separate issues out here:
Sometimes it doesn't show any logs, and a failed (red) status
Let's handle that separately, and do a bit more research before we create a "this does not work" issue. There is known flakiness in how we can retrieve prebuild logs because our domain model relies on checks against to GitHub/GitLab to decide whether you can access a certain resource - and failing to do so would result in this behavior. ☝
Hi, Jan was kind enough to work with me in diagnosing the three bugs here. I'll restate them for clarity:
Clicking the "re-run prebuild" button does not re-run the prebuild. I understand that you're saying that it should not re-run since it was "successful" by some measure, but if that is the case, then the UI should indicate as such, perhaps by re-naming the button. Currently it appears broken because the stated action fails silently, where clicking on the "re-run prebuild" button returns you to the list of prebuilds.
No logs for prebuild. This is one reason why I wanted to re-run the prebuild -- to see what happened. Separately, having logs for all prebuild tasks would be extremely helpful to say the least. https://github.com/gitpod-io/gitpod/issues/9994
When the prebuild failed, at first it said it was successful, and only showed that it errored after reloading the page. Initial:
After reloading:
User's should be served this prebuild when starting a workspace based on it, so they can inspect why it failed in the first place
This does not happen. Because the prebuild failed, workspaces do not use the prebuild. I confirmed this by checking the database row for the workspace and see that basedOnPrebuildId
is empty. Perhaps this is a fourth bug.
Being able to force a rebuild, without conditions, would have saved us a lot of time on our team's initial gitpod setup (and would save us time going forward).
"Without conditions" meaning even if the prebuild succeeded, and even if the commit is the same. Why? External dependencies. For example, we update our custom docker image with some important new thing; currently, we have to push a fake commit to every single existing branch of code to trigger a new prebuild.
Thanks for the feedback, @KayakinKoder! FWIW, we did some design exploration in the past for adding something like this to allow users to re-trigger a prebuild for any branch.
Re-posting here for visibility but I'll also circulate your feedback internally:
Early design on allowing users to re-trigger a prebuild |
---|
we're hitting this a number of times. What is the status ?
Hi @jmls! This issue has not been scheduled to be worked on yet.
Meanwhile, are you able to use the workaround & just push any new commit to the same branch in order to reliably trigger a new prebuild?
oh that's an embuggerance.
Not exactly a great workaround if a developer has to modify source code / add tags just to force a prebuild again :(
I would agree that forcing users to push commits in order to re-run failed prebuilds is not great.
With gitpod doubling prices, we've had to entirely rework prebuilds. The fact that this issue is still open is making it nearly impossible for us to use gitpod in any appreciable manner.
Bug description
A Gitpod customer reports the following:
1234
was pushed tobranch-a
abcd
was triggered for commit1234
onbranch-a
, but eventually the prebuild failedRerun Prebuild (branch-a)
does not actually re-run the prebuild -- instead, it redirects to the list of prebuildsInvestigating a bit further, we see that:
abcd
appears inFailed
state, with the errorThe tasks executed in the prebuild returned a non-zero exit code. headless task failed: exit status 255
abcd
also does not show any logs (maybe another, unrelated bug?)triggerPrebuild
(with commit ID1234
and branchbranch-a
), Gitpod's server responds immediately with:I guess Gitpod considers that commit
1234
already has a successful prebuild, which does not need to be rebuilt, even though prebuildabcd
is actually Failed?Steps to reproduce
Workspace affected
No response
Expected behavior
Expected: Gitpod triggers a new prebuild for the branch, and then shows you its live logs and status
Actual: Gitpod redirects to the list of prebuilds, just as if the latest prebuild had been successful
Example repository
No response
Anything else?
No response
Front conversations