Change the git-userdata configmap to secret

[vinokurig]

What does this PR do?

Store the gitconfig automaunt content to secret instead of configmap. This is needed to have all gitconfig automaunt values in one secret as devworkspace operator does not support mount to gitconfig from multiple objects.

The goal of having a single place to mount gitconfig values is that we need to mount additional gitconfig section apart from the [user] section. Currently we mount only username and email from the workspace-userdata-gitconfig-configmap configmap but in the scope of the Azure devops server support we also need to mount azure token as an http.extraHeader value:

[http]
    extraHeader: Bearer <azure token>

We can not mount the http section in a separate secret because devworkspace operator does not support gitconfig mount from multiple objects, see https://github.com/devfile/devworkspace-operator/blob/a6ec0bfb254ae1f63283b507475fba69b9768ac5/pkg/provision/automount/common.go#L223-L225.

Screenshot/screencast of this PR

What issues does this PR fix or reference?

eclipse-che/che#23306

Is it tested? How?

1. Go to the user preferences -> Gitconfig
2. Set up username and email

See: the data is stored to the devworkspace-gitconfig-automaunt-secret Secret in the user namespace.

Release Notes

Docs PR

[che-bot]

Click here to review and test in web IDE:

[ibuziuk]

@vinokurig what about backward compatibility?

[github-actions]

Docker image build succeeded: quay.io/eclipse/che-dashboard:pr-1313

kubectl patch command

kubectl patch -n eclipse-che "checluster/eclipse-che" --type=json -p="[{"op": "replace", "path": "/spec/components/dashboard/deployment", "value": {containers: [{image: "quay.io/eclipse/che-dashboard:pr-1313", name: che-dashboard}]}}]"

[vinokurig]

@ibuziuk

what about backward compatibility?

We do not have the backward compatibility yet. To have it we can:

• Use the current workspace-userdata-gitconfig-configmap as the single place to store the gitconfig mount. cons:
  • Sensitiva data such as tokens should be stored in a secret.
  • The configmap name is too specific to store other then username and email data.
• Deprecate the configmap and add a temporary mechanism that will transfer data from the configmap to the new secret.

WDYT?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.88%. Comparing base (f2e8000) to head (af05927).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1313      +/-   ##
==========================================
+ Coverage   91.65%   91.88%   +0.23%     
==========================================
  Files         500      500              
  Lines       45489    45494       +5     
  Branches     3173     3187      +14     
==========================================
+ Hits        41691    41803     +112     
+ Misses       3766     3660     -106     
+ Partials       32       31       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[olexii4]

@vinokurig I tested this PR with Dashboard Version 7.99.0-next.

Before update:

After update:

Let's read the git-userdata(if they exist) from configmap and store it into secret. Then, removed the git-userdata from configmap.

WDYT?

[vinokurig]

@olexii4
I have fixed the issue with the previously stored data in the related che-server pull request eclipse-che/che-server#754

[olexii4]

LGTM

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: olexii4, vinokurig

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[tolusha]

I faced the same problem, I can't see gitconfig after switching to the new image.
BTW, we have to update the doc as well
https://eclipse.dev/che/docs/stable/end-user-guide/mounting-git-configuration/

[ibuziuk]

I'm wondering how this change would be working from the backward compatibility perspective?
e.g. if there is a cm with gitconfig once the new version of the project is rolled out would the gitconfig be blank?

[vinokurig]

We decided to close this pull request and go with using the current configmap.