opslevel manifest

[jcchavezs]

Hi Opslevel,

I see the opslevel.yml file in this repository and I was wondering if this should be declared as a service or as a repository. My hunch says this is not a service as it a library for a API client and would never operate as a service or be run, instead it will be consumed.

My concern is that when using this library and more so when checking in this library into the codebase because you vendored dependencies opslevel platform will import this opslevel.yml into the platform creating a misleading service.

Am I missing something?

[rocktavious]

Hey @jcchavezs - we actually use that OpsLevel internally having our own account for tracking all the things our company is responsible for.

While its called a "service" in the platform nothing stops you from making "services" for things that are not running services like libraries and OSS tools you fork etc etc. The main problem the catalog solves is understanding everything your team owns and then running maturity checks upon those things. opslevel-go is something we own and need to track and improve the maturity of just like anything else we write code for (or have forked the code of).

Hopefully that helps you understand where we are coming from.

Now onto the problem of vendored dependencies and opslevel.yml - this is likely an unexpected edgecase for our product and something I can take back to the product teams to see if they can do some magic exclusion or at least give you the option to exclude. Definitely an interesting problem.

[jcchavezs]

Yes, indeed this is common case when you do vendoring. One weird outcome of this is the following:

1. Repository A contains code for service A along with other things (think of a monorepo)
2. Repository B contains code for service B and it imports packages from Repository A and of course vendors it but that code isn't necessarily connected to service A.

The outcome is that since repository B vendors repository A it will checkout the entire repository (and hence all the opslevel.yml files in the repo) although the packages used are not connected to the components described by those opslevel.yml.

[rocktavious]

@jcchavezs - So we had a discussion internally and since our roadmap at least for the next quarter is not going to include any product changes to support magic exclusions or giving the option to exclude a nested opslevel.yml we are ok for the time being with removing the file.

I will be setting up a campaign internally and we'll be removing it from all our libraries untill we can have a better product solution for this edgecase.

Thanks for bringing this to our attention.

[jcchavezs]

Thanks for the quick response!

[jcchavezs]

A new release is out https://github.com/OpsLevel/opslevel-go/releases/tag/v2024.5.13