unable to clone a repository when github oAuth is enabled

[benoitf]

Describe the bug

Trying to import a private github project, project is not cloned

Here is the log in project-clone container:

2022/01/13 12:40:29 Using temporary directory /projects/project-clone-3799693940
2022/01/13 12:40:29 Read DevWorkspace at /devworkspace-metadata/flattened.devworkspace.yaml
2022/01/13 12:40:29 Processing project my-private-repository
2022/01/13 12:40:29 Cloning project my-private-repository to /projects/project-clone-3799693940/my-private-repository
Cloning into '/projects/project-clone-3799693940/my-private-repository'...
fatal: could not read Username for 'https://github.com': No such device or address
2022/01/13 12:40:29 Encountered error while setting up project my-private-repository: failed to clone project: failed to git clone from https://github.com/benoitf/my-private-repository.git: exit status 128

Che version

next (development version)

Steps to reproduce

1. install che with che/next and DWO/next. / chectl server:deploy --platform=openshift
2. setup github oAuth by configuring a secret / https://www.eclipse.org/che/docs/che-7/administration-guide/configuring-authorization/#enabling-authentication-with-social-accounts-and-brokering_che
3. import a private project (I created a dummy empty repository on github and made it private)

There are issues when cloning the repository in project-clone container

Expected behavior

I expect that the project is cloned

Runtime

OpenShift

Screenshots

Installation method

chectl/next

Environment

other (please specify in additional context)

Eclipse Che Logs

No response

Additional context

If I manually clone the repository with the username and token stored in the personal-access-token secret it works

[amisevsk]

Is this really a DevWorkspace Operator issue? We've discussed configuring git settings in the DWO repo numerous times (e.g. devfile/devworkspace-operator#613, devfile/devworkspace-operator#506), but this issue is that the Che documentation doesn't lead to the correct result.

Either the Che docs should be updated to use a DWO-supported flow, or the Che side should be updated to use a DWO-supported flow from the documented Che flow. DWO can't look at a secret with a definition like

kind: Secret
apiVersion: v1
metadata:
  name: github-oauth-config
  namespace: <...> 
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: oauth-scm-configuration
  annotations:
    che.eclipse.org/oauth-scm-server: github
type: Opaque
data:
  id: <...> 
  secret: <...> 
EOF

and do anything.

[benoitf]

Well, I've added the component that is failing to perform the clone which is project-clone.

Either the Che docs should be updated to use a DWO-supported flow, or the Che side should be updated to use a DWO-supported flow from the documented Che flow. DWO can't look at a secret with a definition like

Che is looking at this secret and creates a personal-access-token in the user namespace

kind: Secret
apiVersion: v1
metadata:
  name: personal-access-token-g81il
  namespace: user
  uid: 057539c2-3b40-4043-9573-172c35cb51fb
  resourceVersion: '63453'
  creationTimestamp: '2022-01-13T12:20:54Z'
  labels:
    app.kubernetes.io/component: scm-personal-access-token
    app.kubernetes.io/part-of: che.eclipse.org
  annotations:
    che.eclipse.org/che-userid: id
    che.eclipse.org/scm-personal-access-token-id: id-lj1nx
    che.eclipse.org/scm-personal-access-token-name: oauth2-axdkb
    che.eclipse.org/scm-url: 'https://github.com'
    che.eclipse.org/scm-userid: '123'
    che.eclipse.org/scm-username: my-username
data:
  token: myToken
type: Opaque

if there are missing annotations, etc, feel free to assign the right area but here I've a secret token that is not used when cloning.

[ibuziuk]

or the Che side should be updated to use a DWO-supported flow from the documented Che flow

@skabashnyuk as I recall Che is using the right DWO format already? not sure if this is documented though

@benoitf https://www.eclipse.org/che/docs/next/administration-guide/configuring-authorization/#enabling-authentication-with-social-accounts-and-brokering_che is 404 🤷‍♂️

[benoitf]

https://www.eclipse.org/che/docs/che-7/administration-guide/configuring-authorization/#enabling-authentication-with-social-accounts-and-brokering_che

old doc was removed 1hour ago eclipse-che/che-docs@bdb9b9c

[amisevsk]

As linked in devfile/devworkspace-operator#506, the secret should look like

kind: Secret
apiVersion: v1
metadata:
  name: git-credentials-secret
  annotations:
    controller.devfile.io/mount-path: /home/theia/.git-credentials/
  labels:
    controller.devfile.io/git-credential: 'true'
    controller.devfile.io/watch-secret: 'true'
data:
  credentials: >- ${your base64 credentials here}
type: Opaque

(see devfile/devworkspace-operator#564)

There may be controller-side issues with handling personal access tokens, but we're not hitting a DWO-enabled flow at all yet.

[benoitf]

the mount-path looks strange anyway in your example as the container that is cloning is project-clone container and also most of the stuff is done inside the universal developer image now (which has not a /home/theia)

[amisevsk]

the mount-path looks strange anyway in your example as the container that is cloning is project-clone container and also most of the stuff is done inside the universal developer image now (which has not a /home/theia)

Sure, that description is half a year old, the point is that the mechanism isn't engaging with DWO at all.

[amisevsk]

Followed the flow described above in DWO and apart from one recently-introduced issue (fixed in devfile/devworkspace-operator#737), it works without significant problems.

[skabashnyuk]

@benoitf did you get git-credentials-secret- in your namespace after successfully completing OAuth flow?

[benoitf]

@skabashnyuk yes I've git-credentials-secret-70icn and personal-access-token-g81il secrets

kind: Secret
apiVersion: v1
metadata:
  name: git-credentials-secret-70icn
  namespace: opentlc-mgr-che
  uid: 636642fd-54db-4f73-9c70-05cd5fe2c6b8
  resourceVersion: '63633'
  creationTimestamp: '2022-01-13T12:21:08Z'
  labels:
    app.kubernetes.io/component: workspace-secret
    app.kubernetes.io/part-of: che.eclipse.org
    controller.devfile.io/git-credential: 'true'
  annotations:
    che.eclipse.org/automount-workspace-secret: 'true'
    che.eclipse.org/che-userid: 1ced06f3-0d1b-48f8-8512-da46c6128a12
    che.eclipse.org/git-credential: 'true'
    che.eclipse.org/mount-as: file
    che.eclipse.org/mount-path: /home/theia/.git-credentials
    che.eclipse.org/scm-url: 'https://github.com'
    che.eclipse.org/scm-username: benoitf
    controller.devfile.io/mount-path: /home/theia/.git-credentials

but mount-path is /home/theia so I think it doesn't work

[skabashnyuk]

The problem is only in /home/theia path? What path has to be set?

[benoitf]

I need to have the credentials in theia container, in project-clone init container and probably in my dev/universal developer image (it's the container that user will use)

[skabashnyuk]

I was not aware of changes in dev/universal developer image or devworkspace controller. @benoitf @amisevsk can you tell me the exact labels and annotations that have to be set?

[l0rd]

@skabashnyuk we are not setting label controller.devfile.io/watch-secret: 'true' and the controller is not mounting the secret: #21027

[amisevsk]

The path ultimately doesn't matter, but is ideally a location that the container can edit (otherwise, git will complain about being unable to lock the file during clone).

What DWO does for git credentials is

1. Mount secret to defined path (e.g. /home/theia/.git-credentials/credentials)
2. Mount a gitconfig with

   [credential]
           helper = store --file <path-to-credentials>
   

   to /etc/gitconfig (see potential issue Automounted git-credentials can collide with manually defined gitconfig devfile/devworkspace-operator#744 as well).

This means that any git-credential is applied to all containers in a DevWorkspace.

[skabashnyuk]

fixed in eclipse-che/che-server#245