test: remove git initializer TargetMode and CloneTaget

[jenting]

Description

Remove git initializer TargetMode and CloneTaget in the workspace integration test.

Related Issue(s)

Fixes #13278

How to test

Running the integration test, make sure the integration test pass.

Release Notes

None

Documentation

None

Werft options:

• /werft with-local-preview
  If enabled this will build install/preview
• /werft with-preview
• /werft with-integration-tests=workspace
  Valid options are all, workspace, webapp, ide

[jenting]

/hold

Waits for the integration test pass

[kylos101]

👋 @jenting can you share context for this PR? For example, the issue you linked to is closed. Is there a new issue or problem that was reported?

edit: I assume you are referring to this comment? #13241 (comment)

[jenting]

👋 @jenting can you share context for this PR? For example, the issue you linked to is closed. Is there a new issue or problem that was reported?

edit: I assume you are referring to this comment? #13241 (comment)

Yes, because we could fix it within 5 mins, so I did not bring up the issue originally.
I just created the issue and updated this PR description.

[werft-gitpod-dev-com]

started the job as gitpod-build-jenting-revert-git-ls-remote-exit-code.2 because the annotations in the pull request description changed
(with .werft/ from main)

[werft-gitpod-dev-com]

started the job as gitpod-build-jenting-revert-git-ls-remote-exit-code.5 because the annotations in the pull request description changed
(with .werft/ from main)

[jenting]

This PR is blocked by issue #13284.

[werft-gitpod-dev-com]

started the job as gitpod-build-jenting-revert-git-ls-remote-exit-code.7 because the annotations in the pull request description changed
(with .werft/ from main)

[jenting]

/werft run

👍 started the job as gitpod-build-jenting-revert-git-ls-remote-exit-code.8
(with .werft/ from main)

[utam0k]

I have one question. Should this modify the test, or is this something that contentInitializer should handle (or ignore)?

[jenting]

I have one question. Should this modify the test, or is this something that contentInitializer should handle (or ignore)?

I use Jaeger to catch the initializer sent from the server, and it does not contain the TargetMode and CloneTarget from the start workspace request. That's why we can't reproduce it when we open the workspace from Gitpod GUI.

For the short term, we could fix it with an integration test.

But I am thinking about the long term. We should change the workspace integration test that sends requests from integration test client -> server -> ws-manager, rather than from integration test client-> ws-manager.
After that, we could test against the real code logic, WDYT?

[utam0k]

For the short term, we could fix it with an integration test.

But I am thinking about the long term. We should change the workspace integration test that sends requests from integration test client -> server -> ws-manager, rather than from integration test client-> ws-manager.
After that, we could test against the real code logic, WDYT?

Make sense 💯 Please put TODO comment about it to the integration test.

[jenting]

/werft run

👍 started the job as gitpod-build-jenting-revert-git-ls-remote-exit-code.10
(with .werft/ from main)

[jenting]

/unhold