It should be easier to configure remotes in Devfile v2 flow

[amisevsk]

Is your enhancement related to a problem? Please describe

By default, I set up repos I work in with remotes

  upstream: <the main repo -- e.g. github.com/eclipse/che>
  origin: <my fork of the repo -- e.g. github.com/amisevsk/che>

However, with the devfile v2 flow, only one repo can be specified and the devfile from that repo is used for the workspace. This can lead to issues if a fork is out of date, and requires adding remotes manually after the fact.

Describe the solution you'd like

Ideally it would be possible to specify a full list of remotes that the workspace should use. If not that, specifying (or automatically detecting) a fork + upstream set of remotes would be very useful

When cloning a new repo for the first time, I would like it to be configured so that

1. The upstream remote is cloned, in order to pull the latest changes from main into the workspace and track upstream/main in the local main branch
2. The origin remote is configured, allowing me to push branches to origin in order to open a PR

Describe alternatives you've considered

No response

Additional context

On a DevWorkspace level, the configuration looks like

projects:
  - name: che-docs
    git:
      remotes:
        upstream: 'https://github.com/eclipse-che/che-docs.git'
        origin: https://github.com/amisevsk/che-docs.git
      checkoutFrom:
        remote: upstream
        revision: master

(revision can be omitted if the default branch is to be used)

Related issue: Sometimes Che-Theia overwrites the DevWorkspace CR when adding remotes via UI: #21244

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[amisevsk]

/remove-lifecycle stale

[l0rd]

@amisevsk to clarify: on the devfile / devworkspace API level everything is already there. What's missing is something like a remotes URL parameter that the dashboard can process and inject in the DevWorkspace object. Is that correct?

[l0rd]

In this case, with the help of a browser extension, we could make it automatic.

[amisevsk]

Right, devfiles/devworkspaces support everything that would be needed to support this currently, and it's possible to manually create a devfile that works as expected.

I'm not sure an ideal solution, and maybe a browser extension is the best option. Overall the outcome I would want is that when I start a workspace e.g. https://github.com/eclipse-che/che-operator, the remotes automatically get configured also include my fork (https://github.com/amisevsk/che-operator). Fully automating that may not work though, as there's potentially different remote naming conventions (I use origin and upstream, for example). Ideally it wouldn't require a browser extensions but I don't know that I see an easy way to do it unless the GitHub/GitLab/Bitbucket apis provide easy ways of getting the current user's fork.

[l0rd]

I am assuming this can be closed now