shivenduverma-sap
commented
1 year ago Relevant comments from open-component-model/ocm-project#100 about this issue:
[Skarlso]
This will simply not work and would prove a huge security risk for local development. Please read the attached Module Reference guide to understand the need for the sum file. On top of that, we would like to avoid non-go approaches, please. :) The generated sum file could provide different SHAs from what the developer is using. This, in-turn, could provide functionality problems, or conflicts during commits which would lead to a frustrating workflow. Further, go mod tidy also modifies the mod file. This would mean if the developer isn't running that correctly, that's a further problem in ci when its trying to download and update the sum file.
But the two main concerns are this:
The go.sum is generated for the project in the pipeline and commited to git
How would this work if it's ignored?
And second, if there is no sum file, or a generated sum file in the repository, that would cause problems with contributors checking out the code. If there is no sum file, they could generate a completely different sum file which is a security risk. Second if, there IS a sum file but it's different from what is generated that's a security issue because the generated sum file could be missing a CVE fix.
To better understand the problem, look up supply chain attacks with pip and Python. :)
We will have a separate linux image to compile projects and run tests, where we will not download the go.sum file from the repositories but create a new temporary one.
Please search and understand how supply chain attacks work. This is not possible and should be avoided at ALL COST.
Why are we doing this? Any changes to the CLI can lead to failures in business cases which needs to be detected by the mpas e2e tests and ocm e2e tests. The only way this can be recognized is when a developer who made the changes to the CLI, downloads all projects offline, updates go.mod, generates new go.sum and runs the tests locally or creates a PR with the tests will run in the pipeline. This means that they have to edit 8 go.mod files for mpas e2e tests. Something which you can not impose on external contributors.
If an open source contributor works on a test that involves multiple projects and one core element is updated then that's the thing that you have to do in order to test those versions.
Instead, an automation will do this process and notify of a failure due to the changes.
Yes, this is what the e2e test suite is there for.
Why do we need an automation and why cant we rely on a developer to detect the changes when they update the cli in controllers to the latest version? Because nobody wants landmines and wasting a day before starting a new ticket.
Because updating a dependency should never be done automatically before a human verifies everything is okay. Besides, dependabot exists. It is there to update dependencies. And the e2e suite is always testing latest versions together with each other. That is its purpose.
If you look at how open source development works at Apache, the tests are run on the code before the Apache collaborator even reviews the code that is written by an external contributor for a ticket. We need this process.
Sure. That is the e2e testing framework.
In addition if dependencies are not checked in, some thing locally might work, but they might actually NOT work on CI because it checks out something completely different.
Further, Go blog itself and the best Go practice specifically outline checking in go.mod and go.sum files into version controller. You can't just generate these independently.
souleb
User Story: CI Solution to enable e2e-testing in pipelines against PR without having to pull other projects
Description: We need a CI solution to pick up latest changes and test with e2e tests to notify if there will be failures due to the possible changes. It wont block/fail the PR, it is also informative. Devs should not be required to run tests locally
An example why is it a problem in the current setup?
The following projects in OCM org use ocm-cli as a dependency
If there is a change in the ocm-cli, the assignee of the ticket should be able to test if the new changes are breaking the tests of all the projects and the 2 e2e test suites. This problem is not just because of the ocm-cli, could be the e2e-framework, etc.
Proposed Solution
Epic link: