start:bugfix wrong interpretation of subversion of docker #1156
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
- What I did
Changed how we check the docker version to accept single digits.
More about the issue here: #1154
Also, this issue can be connected: #1155
I also changed some tests that run on "make test" - as two tests failed locally.
More details:
When we validate the docker version, we read the version and subversion from specific characters of the string that represent the version. As in some cases, subversion has one digit instead of two, subversion's string consists of a number and "." for example, "0.". When we pass such string to strconv.Atoi, we receive an error. This cause the error in version validation.
The simplest proposed solution is to split a string on "." - if we have "X.", it will grab X, if there is no dot - everything will still work.
A better solution would be to split the whole string correctly and grab specific version and subversion string as described in the issue #1154. But as other users have a similar problem #1155, this hotfix should be enough for the moment.
Additional changes are connected with running tests locally with the command "make test". If we pull only this repository, we do not have a directory
filepath.Join(testutil.RootPath, "..", "horusec-examples-vulnerabilities")
, so the test fails. This is why it was replaced withtestutil.RootPath
. This way, tests can be run on that code without errors by everyone independently from other projects. But probably, the test stopped to test specific cases. I may assume that that missing directory contained some vulnerabilities that would be found by horusec but should be ignored with the defined configuration, and this way test passes. Now it is passing as there are no directories with issues, not due to ignoring them during test... I suggest creating another ticket to fix that specific test.The last change was also connected with tests. When we run tests, directory
.horusec
is created that contains a copy of all files and directories. So when we runfile.GetPathFromFilename(filePath, volume)
inTestGetFilePathIntoBasePath
returns the path from.horusec
subfolder, not from the root ex..horusec/8faf537b-f096-4665-ac8b-0810beb4a574/internal/utils/file/file_test.go
instead ofinternal/utils/file/file_test.go
. This way, assert.equal failing. With little changes in directories that we search and assertion, the test pass (and is still correct).- How to verify it
For a fix on docker validation, it is enough to test it on the configuration mentioned here: #1154
First, test the master branch, and later test the fixed version.
For changes in tests, you should clone the repo on a fresh environment without any other repos/projects and pull the master branch - check the errors on "make test". Next, check the same way the changed version. Tests should pass now.
- Description for the changelog
Support single-digit subversions of docker