search

pipe-cd / pipecd

The One CD for All {applications, platforms, operations}
https://pipecd.dev
Apache License 2.0
1.07k stars 149 forks source link

Let's discuss about Git client #4791

Open sivchari opened 7 months ago

sivchari commented 7 months ago

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:

sivchari commented 7 months ago

@ffjlabo @khanhtc1202 @nnnkkk7 @moko-poi

khanhtc1202 commented 7 months ago

@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 commented 7 months ago

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 😁

github-actions[bot] commented 1 month ago

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.