Find a better name for "infrastructure service"

[mnonnenmacher]

The InfrastructureService class is a combination of a service URL and credentials used to access the service. Service in this context means something like a Git repository host, or an artifact repository.

To me the name "infrastructure" is a bit confusing, because it makes me think of deployment infrastructure and it does not really add anything to just calling it "service". Also, the name does not give a hint that it includes also credentials for that service.

Therefore, I would propose to find a clearer name for this, for example, ServiceConnection. It would be interesting to learn what others think about this.

[sschuberth]

I like ServiceConnection. Maybe also AuthentictionService or AuthenticationProvider?

[mnonnenmacher]

I tend to prefer just Credentials or maybe Service Credentials now, because I think these names are even clearer for users who might also not immediately have an idea what a ServiceConnection is for.

[wkl3nk]

... Service in this context means something like a Git repository host, or an artifact repository.

I do no longer agree to the part about "artifact repository".

There was a paradigm shift, to no longer define Infrastructure Services in the UI or using the REST API, but instead define them in a .ort.env.yml file in the user's source code repository. This approach has many benefits. We already in the UI have stripped the functionality down to generate the information into a "Netrc file" and a "Git Credentials file" only.

Proposal:

• Get rid of "Infrastructure Service" term in the UI or REST API totally.
• To enable "repositoy bootstrapping", when the user creates a new repository, let him also specify the credentials (username and password/PAT secret) (if required) and create the Infrastructure Service for Netrc file and Git Credentials file in the backend.

[mnonnenmacher]

Personally, I also have a preference for config as code and would probably use the .ort.env.yml in projects I'm working on, but when there are a lot of repositories sharing the same configuration, like the same Artifactory credentials, it can be more convenient to configure them globally.
There might also be users who cannot modify the source code of the project they want to scan, for example, because they need to scan an old release. For these it should still be possible to configure credentials in the UI/API.

[oheger-bosch]

I agree with @wkl3nk that infrastructure services are a hard to grasp concept, and we should try in the UI to hide it as much as possible for users. However, I also see the use case of a central artifact repository that is to be used by many projects; here it would be beneficial to have a single declaration instead of redundant ones in the configuration files of all projects.

One thing that makes infrastructure services difficult to understand is that they are an abstraction for different concrete things: the (source code) repositories to scan, and the (artifact) repositories used within these scans. Maybe it is possible in the UI to focus only on the latter by handling the source code repositories in a different and more implicit way: There was already the idea to specify credentials when creating a new (source code) repository. So, in this scenario, users only see the repository and its properties, but no infrastructure service. To avoid redundancy if there are multiple repositories sharing credentials (e.g. in the same GitHub organization), the properties of organizations and products could be extended to support a repository base URL with default credentials. Then, for every repository matching the base URL, these credentials would be used unless they are explicitly overridden. Behind the scenes, infrastructure services managing the credentials can be created without the users having to deal with them.

If source code repositories are handled in this way, so-to-say transparently for users, the UI for infrastructure services could then focus on artifact repositories - and then, corresponding terminology can be used, making it clearer what users actually have to configure.