Launching manual prebuild via URL keeps reloading the page

[shaal]

Bug description

When using gitpod.io/#prebuild/<repo_url>
Page keeps reloading itself every second, eventually gets to this screen -

While this is happening, open a new tab with gitpod.io/#<repo_url> (without prebuild), the screen shows a prebuild is running (terminal view), but nothing is happening.

When the process is done, opening the repo URL in Gitpod works fine, and it seems that prebuild ran successfully.

Steps to reproduce

1. Open https://gitpod.io/#prebuild/<repo_url>
2. Confirm page is reloading itself in a loop

Workspace affected

No response

Expected behavior

No response

Example repository

No response

Anything else?

No response

[jldec]

Also reported by another user via support.

[jldec]

/schedule

[roboquat]

@jldec: Issue scheduled in the meta team (WIP: 0)

In response to this:

/schedule

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.

[jldec]

I tried this with one of my repos: https://gitpod.io/#prebuild/https://github.com/jldec/asyncbuilder.git
It produced a redirect loop with 10 calls to /start/

[gtsiolis]

Cross-linking relevant discussion from discord.

[geropl]

This just triggered an incident because error rates went up. We should fix this before it get's costly again. 🙂

[jankeromnes]

We previously agreed to deprecate this manual prefix (#/prebuild/<repo>) in favour of the new Teams & Projects Run Prebuild button. Also, the manual prefix implementation is no longer correct (it doesn't associate Projects to prebuilds, doesn't use Incremental Prebuilds if enabled, etc).

Maybe we can mark this prefix as deprecated in the docs and make it redirect to the most sensible place.

I can give this a go:

/assign

[jldec]

I just repro'd another redirect loop with 28 cycles by prefixing a minmal repo which contains just a readme.

I would prioritize as follows:

1. fix or disable the redirect loop on manual /#prebuild/ contexts
2. if we simply disable it, we need some text to show people in the UI and docs page to link to. (opened issue Disable /#prebuild/ prefix #6779 for that)
3. dropping users into the project would be nice but I would not spend a lot of time perfecting that, since it only works in a subset of cases.

[shaal]

The new Projects UI is great, and a redirect or message for anyone who try using /#prebuild/ sounds good.
We're still missing a Run Prebuild button in the UI, so there's no way to manually run prebuilds, unless you push a new commit to the branch.

[jankeromnes]

We're still missing a Run Prebuild button in the UI, so there's no way to manually run prebuilds, unless you push a new commit to the branch.

Ah, you're right. There is a Run Prebuild button, but it's only available for Prebuilds that have failed or been cancelled. You cannot re-start a new Prebuild for a commit that was already Prebuilt (because we assume the new Prebuild will be identical to the already-existing Prebuild -- no need to re-do the same successful work twice).

Another reason we did that was that a lot of the Prebuild code assumes that a single commit can only have a single (successful) Prebuild associated to it.

Could you please provide more details on your use case for triggering new Prebuilds without pushing new commits? (I believe you use that to make the running Prebuilds interactive, and SSH into them to observe or live-debug them, right?)

[shaal]

@jankeromnes that too.
Sometimes, certain things during prebuild just randomly fail (like download docker images, and there was a network issue that moment).

In upcoming version of DrupalPod, I offload the whole "full" prebuild process (that would take half an hour) to a separate manual process. During prebuild itself, I just download the artifacts that were produced during the manual process from Google Cloud. So when something external changes, and my repo fetch that during prebuild, I'll need to re-run prebuild.
prepare-environments-gcs.sh is called during init start-task in .gitpod.yml
https://github.com/shaal/DrupalPod/pull/46/files#diff-5653e74655e1ac0142dd271fd9ecd636bb1d23857760ca01c0e8ea5f92b0b76f

[shaal]

One more thought before we shut down the manual prebuild URL -

I am thinking of moving DrupalPod from GitHub to Drupal's own Gitlab self-hosted instance (i.e. https://git.drupalcode.org/project/drupalpod)
How do I manage or trigger prebuilds when it's not on Github.com or Gitlab.com?

Currently, I can manually trigger that repo with /#prebuild and get the prebuild running.
But without that, EVERY user that will open that repo, will have to watch and wait for all the prebuild steps only after their workspace interface opened.

I cannot add that project - https://git.drupalcode.org/project/drupalpod to my gitpod.io/projects page, so I cannot manage it through the UI.

[jankeromnes]

One more thought before we shut down the manual prebuild URL -
[...]
How do I manage or trigger prebuilds when it's not on Github.com or Gitlab.com?

Currently, I can manually trigger that repo with /#prebuild and get the prebuild running.

Ah, indeed you're right, that's an excellent point. If we disable the /#prebuild/ URL prefix, we essentially prevent anyone from enabling prebuilds on Bitbucket or GitLab Self-Managed. 🤦

I guess this sort of disqualifies 2. and 3. from #6688 (comment), leaving only:

1. fix or disable the redirect loop on manual /#prebuild/ contexts

as a reasonable option. Let's see if I can understand and fix the redirect problem.

[jankeromnes]

Okay, @AlexTugarev identified that the infinite redirect loop is likely caused by this fix 1de8d78 currently not being deployed on workspace clusters.

So, this bug will likely be resolved by the next workspace cluster deployment.

/unassign
/unschedule

[shaal]

Thank you @jankeromnes
Unrelated to this topic specifically, more general Gitpod question - are there tests written for each feature in Gitpod? If yes, I would assume test would break showing that a code change made another functionality stop working. If no, is there a reason or a plan of when tests will be implemented?

[jankeromnes]

I like this question 😁 we do have some tests (e.g. unit tests for some things like DB entities & persistence), but this bug highlights an area were we still should improve. I know of some integration tests we've built (but they are not reliable enough, so we typically ignore them, which makes the problem worse 🙈) and I've heard about plans to have interactive UI tests in the IDE, but all-in-all, I'd say our testing situation isn't that great yet.

[iQQBot]

Has this issue been solved? I am currently unable to reproduce this issue. （on prebuild scenes） @shaal
Close the issue if it has been solved

[shaal]

I cannot replicate this issue any more.

Do you know what was the code that broke / the code that fixed it?

[iQQBot]

Okay, @AlexTugarev identified that the infinite redirect loop is likely caused by this fix 1de8d78 currently not being deployed on workspace clusters.

So, this bug will likely be resolved by the next workspace cluster deployment.

/unassign /unschedule

@shaal I think maybe this.
Since it has been solved, I will now close the issue, if encountered again welcome to reopen

[iQQBot]

Only the problem of prebuild failure is addressed here, and the infinite loop will be addressed in a separate issue