fatal: 'origin/branch-name' is not a commit and a branch 'branch-name' cannot be created from it

[kylos101]

Bug description

In gen59, we see errors like:

We must be hitting this error, which gets traced here.

Steps to reproduce

Not sure.

Maybe try starting a workspace, and delete the remote branch before the workspace starts, ideally after context parsing, before loading the content.

Workspace affected

n/a

Expected behavior

1. We should log this as an error, not debug, so we can see in the logs w/o enabling debug
2. We should return a clear message to the user when this happens.
3. We shouldn't retry so many times for so long

Example repository

No response

Anything else?

No response

[jenting]

I check the spans and corresponding logs, a case happens in prebuild, and the remote branch does not exist anymore.

[kylos101]

Still seeing this issue with prebuilds [1][2] in us60

[kylos101]

@atduarte adding back to scheduled

[jenting]

Still seeing this issue with prebuilds [1][2] in us60

The way to reproduce it is when running prebuild, the remote branch is deleted at that moment.

[kylos101]

When this happens:

A chain of events occur:

[jenting]

I checked the InitWorkspace span, and I found an interesting thing, all the checkout branch error comes with the users using the additionalRepositories configuration within the .gitpod.yml.

Also, I create a test repo, and I can reproduce it. Just open the repo with the branch test-branch-1, and filter the Jaeger tracing with

• service=content-initializer
• error=true

The problem is that all the additional repositories do not have branch test-branch-1. However, the content-initializer still trying to pull the test-branch-1. If the branch test-branch-1 does not exist, we fall back to pull the default branch.

Note: the user's behavior is correct.

[fitztrev]

This has started happening for me today.

Repo: https://github.com/rosen-score/lila-gitpod

[kylos101]

:wave @fitztrev , thanks for the heads up! This fix will ship next week.

[fitztrev]

@kylos101 thanks for the quick update!

Seems to have started happening today because this change deployed yesterday: https://github.com/gitpod-io/gitpod/pull/11895 And now it does a hard stop if it encounters a git checkout error.

Yes, it probably was due to the fact that the default branch name is different between the main repo and any of the additionalRepositories.

For now, until this gets deployed, I removed the additionalRepositories section and just git clone them individually in the startup script.

[jimmybrancaccio]

Related conversations in Front.

[david-bakin]

Is it gitpod's flow to close bugs before deployment (and before confirmation)? I got this today - see #12118. I didn't find this bug because my default filter is on "is:open".

[atduarte]

@david-bakin Github issues are closed automatically and moved to "Awaiting Deployment" whenever the code that fixes the issue is merged.

Then when we deploy, it is moved to "In Validation".

[mikenikles]

Hey @atduarte, based on your comment this issue has been deployed, can you confirm?

According to Kyle on Discord, issues are only deployed once they have the deployed: workspace label, which isn't the case for this issue here.

[atduarte]

@mikenikles yap! As part of gen61.

The deployed: workspace label is applied to the PRs, not the issues unfortunately.