Let's discuss about Git client
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 1.4k
- Forks
- 364
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 84
Description
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
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading issues 4359 and 4360, then inspect how PipeCD currently uses os.Exec for Git operations. The issue calls for agreeing on a Git interface, identifying default GitHub providers, and planning implementation, but it does not name files, tests, or a concrete completion criterion.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git, go
- Domain
- devops, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100