pipe-cd / pipe-cd/pipecd

Let's discuss about Git client

Open
#4,791 4 comments 5 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

kind/enhancement not-auto-close
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.