-
-
Notifications
You must be signed in to change notification settings - Fork 242
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Determinism in image dependencies #4543
Comments
This will bring us closer and closer to the "My Own MegaLinter Flavor" project :) It will even allow "My Own MegaLinter Flavor with the linter versions I want" thing 🥳 |
@nvuillam the remaining PRs related to this issue are ready for review and merge. |
Once this is done, we should go for the apk/npm/pip dependencies. |
I'm with the remaining packages (a lot of them): apk, cargo, gem, pip and npm. @nvuillam it occurs to me that when we have all this we can on the page of each linter show with shields.io if the packages that each linter depends on are actively maintained, etc .... Just as we do with the linter itself. I have encountered @echoix the following problem:
https://github.com/realm/SwiftLint/pkgs/container/swiftlint Can you think how to make renovate update the tag? It would be necessary to create a custom manager or similar I guess, no? Right now by not putting the tag, it implicitly pulls latest... |
There's a megalinter/megalinter/Linter.py Line 100 in c047fd7
So now we only need to get that field updated. I searched on our GitHub repo for swiftlint, but I didn't see the image appear somewhere in the generated files. |
PR created but I'm still working on it: #4588 I had to change in build.py how the “core” dependencies are added so that they are also versioned. |
@bdovaz i have a question and i'm afraid of the answer ^^ When we'll upgrade base image alpine version, we'll have all apk pinned to versions that do not exist in , so in my worst case scenario imagination:
Please can you reassure me ? ^^ I wonder it we shouldn't stick to linter versions in the first step, then see for the rest later, to make sure we don't have too much trouble cc @echoix |
@nvuillam if you look at the releases history, they release 2 versions at most per year, I do not think that it's a problem or if for whatever reason we have to do some manual change in that PR we can. https://alpinelinux.org/releases/ It would make me very unhappy after all the hours you've put in on this PR to have to undo something honestly.... I'd rather once or twice a year have to work on those Alpine version change PRs. Actually whenever we upgrade Alpine or Python it is never easy and it always takes some time to make changes anyway. |
Also note that in renovate you can group packages by any criteria you want and one of them can be that the ecosystem is “repology”, that is, that all Alpine packages go in a single PR. |
If you can group alpine version and alpine packages in the same renovate-generated PR, ok for me :) |
Right now, there are many linters that do not have the version of the dependency to install and instead install the latest version available at that time.
This goes against the determinism, security, traceability, etc... Because if you generate the image right now or in 5 minutes you can get completely different versions of dependencies.
In this series of PRs I am trying to partly solve this problem:
#4528 #4529 #4530 #4531 #4532 #4533 #4534 #4535 #4536 #4537 #4538 #4539 #4540 #4541 #4542
I have focused on:
Still a lot of npm, pip, etc.... This can be done in a next phase after merge all those PRs.
cc @nvuillam @echoix
The text was updated successfully, but these errors were encountered: