GitHub proxy part 6.5: tsh git ssh/clone/config

[greedy52]

related:

• GitHub proxy MVP #48762
• GitHub proxy part 6: proxing Git using SSH transport #49980

examples:

$ tsh git config
The current Git directory is configured with Teleport for GitHub organization "goteleport-core-test".

$ tsh git config reset
Teleport configuration removed.

$ tsh git config
The current Git directory is not configured with Teleport.
Run 'tsh git config update' to configure it.

$ tsh git config update
Teleport configuration added.
The current Git directory is configured with Teleport for GitHub organization "goteleport-core-test".

[greedy52]

go-git will be used for the teleport as well.

local mac build tsh increased about 200k (out of 106MB) after importing it.

[github-actions]

🤖 Vercel preview here: https://docs-1vdax8b5f-goteleport.vercel.app/docs

[Tener]

Can you add some context to the implementation choice, i.e, shelling out to git binaries versus using go-git? There are some pros and cons to both and it would be beneficial to hear your reasoning; perhaps worth documenting it in the package itself, too?

On that note, I wonder if we should start splitting the tsh subcommands into their own packages.

We are using git command line interface as the API, which makes it hard to spot any potential mistakes. We don't have infrastructure for this yet, but having an end-to-end suite of tests (including a real github repo and docker image with git) would be amazing.

All those shell invocations makes me wonder about Windows. Can you check if tsh.exe works as intended? (My build command: BUILDDIR=build-win FIDO2=no ARCH=amd64 OS=windows make build-win/tsh && mv build-win/tsh build-win/tsh.exe)

[greedy52]

Can you add some context to the implementation choice, i.e, shelling out to git binaries versus using go-git? There are some pros and cons to both and it would be beneficial to hear your reasoning; perhaps worth documenting it in the package itself, too?

using go-git is an afterthought. By design, we use git under the hood. I've changed the commant to a TODO to investigating the option to use go-git. but overall i feel git binary is more stable (in all platforms) than go-git. And for things like tsh git clone --some-flag (which yet to be implemented), it will be easier to pass extra args directly to git binary then re-implementing the flags through go-git.

On that note, I wonder if we should start splitting the tsh subcommands into their own packages.

It still relies on CLIConf, so would require quite some refactoring to have its own package.

We are using git command line interface as the API, which makes it hard to spot any potential mistakes. We don't have infrastructure for this yet, but having an end-to-end suite of tests (including a real github repo and docker image with git) would be amazing.

Added to TODO list (#48762).

All those shell invocations makes me wonder about Windows. Can you check if tsh.exe works as intended? (My build command: BUILDDIR=build-win FIDO2=no ARCH=amd64 OS=windows make build-win/tsh && mv build-win/tsh build-win/tsh.exe)

I think it should work without issue. I will give it a shot later and submit a separate issue to track it if it doesn't work.

[greedy52]

friendly ping @smallinsky @r0mant

[smallinsky]

The --is-inside-work-tree return true or false:

  --is-inside-work-tree
           When the current working directory is inside the work tree of the repository print "true", otherwise "false".

Just want to ensure that we want to rely on command error and not handle the "false" case ?

[greedy52]

I don't see the false getting printed:

stevehuang@mac ~ $ git rev-parse --is-inside-work-tree
fatal: not a git repository (or any of the parent directories): .git

The fatal error is sent to stderr. Same on my mac or my ec2 linux machine.