Inform PR authors about dependency and version drifts

[shivenduverma-sap]

Description: There are 2 types of dependencies:

1. External dependencies
2. Internal/Cross dependencies from other projects in the OCM github org

Proposal: To help to keep all the projects use the same version, we need a github action/pipeline to:

• parse all DIRECT dependencies in the require() section of the go.mod
• detect dependencies which have multiple versions defined in all projects
• It wont fail/block anything, it is informative

Why?

1. All ocm internal projects should be compatible with the latest versions of the each other, it ensures that e2e-tests are detecting the problems correctly
2. It should not be the responsibility of the person starting a new ticket to do this job before they can start working on their new ticket. The person introducing the incompatibilities has a better knowledge of the changes and should make it part of their existing ticket to fix it or create a separate ticket to fix it. This notification will also help the reviewer understand the outcome of the changes.
3. We will have security scans soon for each individual project, they will scan all dependencies and we should not have repeated/extra vulnerabilities due to different versions of external dependencies

Examples of this problem: 1. https://github.com/open-component-model/replication-controller/blob/main/go.mod#L7 https://github.com/open-component-model/ocm-e2e-framework/blob/main/go.mod#L140 https://github.com/open-component-model/unpacker-controller/blob/main/go.mod#L89 https://github.com/open-component-model/ocm-controllers-sdk/blob/main/go.mod#L10 https://github.com/open-component-model/mpas-product-controller/blob/main/go.mod#L9 https://github.com/open-component-model/ocm-controller/blob/main/go.mod#L7 https://github.com/open-component-model/remote-controller/blob/main/go.mod#L88 https://github.com/open-component-model/git-controller/blob/main/go.mod#L7

2. https://github.com/open-component-model/mpas-product-controller/blob/main/go.mod#L29 https://github.com/open-component-model/remote-controller/blob/main/go.mod#L11 https://github.com/open-component-model/replication-controller/blob/main/go.mod#L19 https://github.com/open-component-model/git-controller/blob/main/go.mod#L22 https://github.com/open-component-model/ocm-e2e-framework/blob/main/go.mod#L283 https://github.com/open-component-model/unpacker-controller/blob/main/go.mod#L15

Epic link:

• open-component-model/ocm-project#100

[shivenduverma-sap]

Relevant comments from open-component-model/ocm-project#100 regarding this issue:

Skarlso commented 2 weeks ago • 👋

Let me try and clarify how dependencies in Go projects work. I highly recommend reading the go modules reference guide in order to fully understand how dependencies are calculated and resolved.

To that end, let me try to clear up some confusion.

Common Dependency Handling: There are a few dependencies which are present in all projects, and we refer to specific versions of a dependency. This created 2 problems:

These are replace statements that are necessary because of OCM, not because of the controllers. OCM deals with a couple of dependencies that require a specific version. These are intrinsic dependencies, and we pin these versions to avoid compiler errors. No one has to revert to anything. These versions already exist on your machine. And you can't use a different one even if you wanted because the project simply wouldn't compile.

This issue is not unique to us. This is a Go based "problem". Even big projects like Kubernetes have replace statements.

Using different dependency versions for different projects. Ideally, they all should be on the same version to get the same functionality and to avoid detecting failing e2e, etc. tests. Eg: ocm-controller versions

Unpacker and remote controller are old. We simply didn't have the time to update them yet.

Have a github actions gather common dependencies from all projects and prevent merging if common dependencies are not on the same/latest version. The versions which should be used should be compiled by the action and stored in a file so that someone who start developing knows the new version they can use locally while developing rather than waiting for the PR to fail and correct before merge

I think that's not necessary. Especially since the mod files will force the versions, they need over the components they dependent upon. If there is a different version requested, they will simply not compile.

ocm cli dependency: The ocm-cli is referred by all projects and apart from the above problem of using different versions, when ever there are changes(refactoring/features) in the CLI, the failures in other projects should be identified and fixed/reported. The failure should not be a landmine for someone starting a new ticket and the failure-fix should be part of the already identified work done on the cli

This problem exists in massive projects that depend on a single source. Just look at CAPA, CAPZ, CAPI projects that depend on Kubernetes. They each have cycles where they update their respective Kubernetes version. And get this. Sometimes they support different versions. ;)

We are a small team. It takes me a full day to update all controllers to the latest OCM version because, usually, it introduces some change that breaks existing behaviour. If it doesn't, it's still at least half a day of work updating the dependencies, approving the PRs, and releasing a new version. This is nothing new, though. And it would be nice to automate it. But the reality is that it's simply not feasible considering the usual changes OCM introduces.

Maybe once we separate the CLI from the Library, it will be an easier task to do so.

[github-actions[bot]]

This issue was marked as stale because it has not had recent activity.