The action tries to help with doing that:
Setting up auth for fetching submodules
/usr/bin/git config --file /home/runner/work/_temp/git-credentials-a27cf341-32c6-456a-b854-e845b34b5cd2.config http.https://company.ghe.com/.extraheader AUTHORIZATION: basic ***
/usr/bin/git config --global include.path /home/runner/work/_temp/git-credentials-a27cf341-32c6-456a-b854-e845b34b5cd2.config
/usr/bin/git config --global --unset-all url.https://company.ghe.com/.insteadOf
/usr/bin/git config --global --add url.https://company.ghe.com/.insteadOf git@company.ghe.com:
/usr/bin/git config --global --add url.https://company.ghe.com/.insteadOf org-1055487@github.com:
But we clone with : company@company.ghe.com suggested from the UI
- git@company.ghe.com
+ company@company.ghe.com
Is that still a bug?
PS: I don't know if it makes a difference but we have GHEC with data residency. Maybe that was left out while developing that feature?
Workaround:
I could just not let the checkout action init the submodule that could help, I have not tested it.
Possible fix:
Extract that git user from the repo meta data information.
Is that related to: #934 ?
The action tries to help with doing that:
But we clone with :
company@company.ghe.comsuggested from the UIIs that still a bug?
PS: I don't know if it makes a difference but we have GHEC with data residency. Maybe that was left out while developing that feature?
Workaround:
I could just not let the checkout action init the submodule that could help, I have not tested it.
Possible fix:
Extract that git user from the repo meta data information.
Is that related to: #934 ?