Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let's discuss about Git client #4791

Open
sivchari opened this issue Feb 16, 2024 · 3 comments
Open

Let's discuss about Git client #4791

sivchari opened this issue Feb 16, 2024 · 3 comments
Labels
kind/enhancement New feature or request

Comments

@sivchari
Copy link
Member

sivchari commented Feb 16, 2024

What would you like to be added:

This isn't new feature that I want to add, but this discussion is too important for PipeCD to determine the way how to handle the Git client.
At the present, PipeCD does the command by os.Exec to operate the Git CLI. But I think it's not good way to operate it. If any error is occurred, the error doesn't have type and if we want the type, then we have to define type in some way. This problem is already mentioned here .
Next, I think we should make the operations of Git abstract. For instance, GitLab names feature request Merge Request, but GitHub names it Pull Request. And we must not know whether both and other Git repository manager treat it in the same way (Sorry if you know).
In fact, it took quite a few days to merge it. Then, this feature can only do until pushing the branch. This because of we didn't know details of other Git software have except for GitHub. Maybe, it might not have been clear even now. I think it might be able to say to other concepts that Git client provides.
Thus, I think it's time to discuss this problem. I think that we should start by discussing the design about Git interface that PipeCD provides.
What do you think ?

Why is this needed:

  • Design the interface
  • Determine GitHub providers PipeCD supports by default
  • Implementation
@sivchari sivchari added the kind/enhancement New feature or request label Feb 16, 2024
@sivchari sivchari changed the title Let's Let's discuss about Git client Feb 16, 2024
@sivchari
Copy link
Member Author

@khanhtc1202
Copy link
Member

@sivchari Making an abstraction for Git is a great idea. Basically, we have done that already. You can see the interface at
https://github.com/pipe-cd/pipecd/tree/master/pkg/git in the source tree.

The thing to mention is that we're using the git command as the implementation for that git interface (not something SDK as you want?). So, instead of designing a new git interface, I guess the problem is finding a universal implementation to support a wide range of git providers.

Another thing to note here is that if you read the PipeCD git package carefully, we're not making a git interface but making it more "objectively", aka actions like push, commit, etc are part of the repository obj (ref: https://github.com/pipe-cd/pipecd/blob/master/pkg/git/repo.go)

@khanhtc1202
Copy link
Member

For the reason why we chose the git command to implement the current "git" interface, we thought that the git command could be the common thing that can work with whatever git providers (since we can actually use the git command client with whatever git providers), and it's also a cost-effective way too (only need to wrap git cli command to connect with any git providers).

But I get your point too, maybe we need a kind of git SDK for each git provider to enable us to use more git providers' functions (like PR creation). If it's possible, you have my both hands support 😁

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants