stacklok / minder / 8755471086 / 1
53%
main: 53%

DEFAULT BRANCH: main
Ran
Files 168
Run time 3s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 47.91% (-0.2%) from 48.143%
8755471086.1

push

github

web-flow 
Implement ProviderFactory and ProviderClassFactory (#3131)

Relates to #2845

Introduce two new constructs for creating providers. The top-level
ProviderFactory takes the name/project or ID of a provider and
instantiates it. In order to instantiate it, it checks the class of the
provider, and delegates it to a ProviderClassFactory, which is
responsible for creating it. This split exists so that we can register
new types of provider while minimizing changes to existing code.

This PR does not make use of the new interfaces. Instead, it just adds
the implementations. This is to simplify review - the process of getting
rid of the ProviderBuilder will involve a large number of small changes
to many parts of code, and that will happen in another PR.

Some points worth noting:

1) This does not provide a ProviderClassFactory for REST or Git since we
   do not use standalone instances of those providers at this point in
   time. It should be trivial to write factories for those at the point
   in time when we need them.
2) Based on discussion with Ozz and Jakub, I have decided to assume that
   the provider class column of the providers table will not be null for
   valid providers. This approach uses the class to figure out which
   concrete type is used to instantiate the provider, and is orthogonal
   to the traits, which describe the set of interfaces which that
   provider can support. In a future PR, I will make the class column
   non-nullable.

8356 of 17441 relevant lines covered (47.91%)

36.97 hits per line

Source Files on job 8755471086.1