Closed lvlcn-t closed 2 months ago
Looks OK, but some things should change as they introduce some complexity we don't need.
I think the biggest problem IMO here is, that we're using the interface in the target manager. The target manager should just have a config; this would have been the gitlab.Config now. Then there would be no need to change the
Bytes()
toSerialize(branch string)
, as the target manager would know which branch it's supposed to talk to.We introduced the abstraction way too soo with no concrete use case. Please let's stop doing this; we've already done a major cleanup on the code base almost a year ago, because it had many premature abstractions which got in the way of our requirements.
Yeah I've also thought about this and maybe we should move some of the additional attributes of the remote.File
type. There are some implementation details that should not concern the target manager. The target manager should only take care about the file name and the content of the file. The rest of the attributes should be handled by the remote.Interactor
implementation, as it is the one that knows how to interact with the registration service, regardless whether it's GitLab or any other service which we might add in the future as an implementation of the remote.Interactor
interface. What do you think about this?
Yeah I've also thought about this and maybe we should move some of the additional attributes of the
remote.File
type. There are some implementation details that should not concern the target manager. The target manager should only take care about the file name and the content of the file. The rest of the attributes should be handled by theremote.Interactor
implementation, as it is the one that knows how to interact with the registration service, regardless whether it's GitLab or any other service which we might add in the future as an implementation of theremote.Interactor
interface. What do you think about this?
@lvlcn-t
The target manager should only take care about the file name and the content of the file.
That's exactly what it should do, well said. The TargetManager
interface was built with a Git Remote backend in mind but was kept also as generic as possible - and we should try and keep it that way at first. The Interactor
interface tries to add an even more generic spin on an already high-level interface.
I'm afraid that's that exactly the problem: the added layer of abstraction with the Interactor
. Each TargetManager
can have its own logic & abstraction on how to interact with the remote (or local) backend and its files. The possibilities are too numerous to count. There's currently no hard requirement (outside of helping us be more generic; as you've noted in your https://github.com/caas-team/sparrow/pull/122) for this feature.
I suggest we discuss this in a smaller circle with @y-eight the next couple of days and see how to move on from here. Since we're mostly expecting people to primarily use Gitlab/ Github to registrer their targets, we should also strive to achieve to facilitate this. I'm pretty sure two different implementations of a TargetManager
would be more than enough.
Motivation
Closes #179
Changes
I've added a configuration option to let the user set the branch to use.
Additional to that, I've also improved error handling of response body close errors and refactored the gitlab interactor to use the (slog.Logger).Context methods.
For additional information look at the commits.
Tests done
Manual E2E tests
Registration Repository
Branch set to
main
Logs:
Repository commits:
Branch set to
registry
Logs:
Repository commits:
No branch configured (defaults to the default branch of the repository)
Logs:
Repository commits:
TODO