Closed lvlcn-t closed 6 months ago
I've started to implement this in feat/git-tarman.
I've tried to keep it as generic as possible, but without using a generic interface for the interactions with the remote state backend. Therefore I've refactored the Gitlab
interface to rather be an Interactor
interface that every implementation for a new remote state backend client needs to implement, just like we kinda already do for the loaders and checks.
CommitFile
with w.Filesystem().Create()
instead of os.WriteFile
CommitFile
and DeleteFile
methodsI've split the whole implementation into three branches (refactor/config-validation, refactor/genericize-tarman, feat/git-interactor) to have smaller pull requests instead of one big ~3k lines changed PR 😅
To ensure I haven't forgotten anything I'll keep the source branch until all three branches are merged.
Is there an existing feature request for this?
Problem Description
As of now, our target manager implementation exclusively supports GitLab through its API for registering the sparrow instances. This limitation restricts the versatility and applicability of our tool, especially for users who utilize other Git-based hosting services.
Proposed Solution
We should refactor the current target manager to leverage either direct Git operations or requesting the GitLab API depending on what the user has configured in his startup config. Additionally this will universally extend our support to any Git-based remote repository.
After implementing this, the configuration options for the target manager will be expanded to include both Git and GitLab, providing users with the flexibility to connect to their preferred Git hosting service. The proposed configuration schema is as follows:
Who Can Address This Issue?
Go devs
Additional Context
https://github.com/go-git/go-git